Beginner's Guide to Interactive Fiction with Inform 7/Getting Started with Inform 7

Your First GameEdit

Interactive fiction games are written in a programming language, of which there are many. Inform is one of them. The documents written in the language that define the game are called source code. Unlike previous versions of Inform, version 7 uses English to describe IF games. Therefore, as a convention throughout this book, we will refer to source text or just source instead of source code.

When you first start Inform and create a new project, you are taken to a dual-pane interface, with each pane having multiple "tabs" at the top. One of these tabs is "Source." The Source tab is where you create the game.

First, we begin with the simplest possible game: a single room into which the player is dropped.

"Ruins Remixed" by Brandon Felger

When play begins:
say "[italic type]You are once again lost in a jungle far from home. You are ready to give up and go home, disappointed in yet another failed archaeological expedition. Just as you decide to turn back to camp, you suddenly stumble upon something...[roman type]".

The Forest is a room. "You stand in a clearing in the deep jungle. Obscured by centuries of overgrowth and dim sunlight is a ruined temple of some sort. Whatever details there may have been on the stone blocks have long since been worn away. There is a single, solitary entryway leading downward."

Click the "Run" button. The right-hand pane switches to the "Game" button. Try some various English-language commands:

You are once again lost in a jungle far from home. You are ready to give up and go home, disappointed in yet another failed archaeological expedition. Just as you decide to turn back to camp, you suddenly stumble upon something...

Ruins Remixed
An Interactive Fiction by Brandon Felger
Release 1 / Serial number 061016 / Inform 7 build 3Z95 (I6/v6.31 lib 6/11N) SD

Forest
You stand in a clearing in the deep jungle. Obscured by centuries of overgrowth and dim sunlight is a ruined temple of some sort. Whatever details there may have been on the stone blocks have long since been worn away. There is a single, solitary entryway leading downward.

>examine temple
You can't see any such thing.

>go north
You can't go that way.

>inventory
You are carrying nothing.

>say hello, sailor
(to yourself)
There is no reply.

Examine the source above, and the produced output. The “when play begins” paragraph is known as a rule. The text preceding the colon (:) is the condition that triggers the rule. In this case, when the game is initially run. The text after the colon is the action triggered by the rule. Here, we display a bit of a prelude explaining the story, since interactive fiction is always, in a sense, in media res.

The first room defined is the one we start in. We define the room simply by stating it is so. The quoted text immediately after is the text displayed when the player is in the room. I call it the “LOOK description” since this is what is displayed when a player uses the LOOK command. This convention will also apply to objects, as we will see later.

Introduction to ObjectsEdit

Currently, we are completely unable to interact with the game world in any meaningful way. Let's introduce an object the player can manipulate:

A mushroom is here.

This single line in the source introduces a host of new options for the player:

Forest
You stand in a clearing in the deep jungle. Obscured by centuries of overgrowth and dim sunlight is a ruined temple of some sort. Whatever details there may have been on the stone blocks have long since been worn away. There is a single, solitary entryway leading downward.

You can see a mushroom here.

>take mushroom
Taken.

>examine it
You see nothing special about the mushroom.

>eat it
That's plainly inedible.

>drop it
Dropped.

Not everything we can do with the object is meaningful at this point. For one thing, the mushroom can't be meaningfully examined, and it can't be eaten. Let's make it edible, and add a LOOK description (my own term for the text that is displayed when the player enters the LOOK command) and an EXAMINE description (text that is displayed when the players enters the EXAMINE or LOOK AT command on the object):

A mushroom is here. It is edible. "A polka-dotted mushroom pokes out of the moist soil. It is possibly scrumptious." The description is "Upon further examination, you decide that, while possibly scrumptious, it is also possibly a toadstool."

Inform 7's syntax with respect to what I'm calling LOOK and EXAMINE descriptions are somewhat ambiguous in the source itself. If you say “the description is...”, then you are specifying the EXAMINE description. Now let's run the game:

Forest
You stand in a clearing in the deep jungle. Obscured by centuries of overgrowth and dim sunlight is a ruined temple of some sort. Whatever details there may have been on the stone blocks have long since been worn away. There is a single, solitary entryway leading downward.

A polka-dotted mushroom pokes out of the moist soil. It is possibly scrumptious.

>take mushroom
Taken.

>examine it
Upon further examination, you decide that, while possibly scrumptious, it is also possibly a toadstool.

>eat it
You eat the mushroom. Not bad.

Rules for Doing StuffEdit

Notice that only one of the printed responses to our commands was dictated by our source: the response to the EXAMINE command. Any responses we do not define are “filled in” with default stock responses. We can change the response for taking the mushroom thusly:

After taking the mushroom:
   say "You deftly snap the mushroom's stalk, and pluck the hapless fungus from its natural habitat."

After dropping the mushroom:
   say "You discard the abused mushroom to the ground like a used facial tissue."


>take mushroom
You deftly snap the mushroom's stalk, and pluck the hapless fungus from its natural habitat.

>drop it
You discard the abused mushroom to the ground like a used facial tissue.

Notice that we create rules to override the default messages for these commands. Let create another, more complex rule for the mushroom:

After eating the mushroom:
   say "You pop the scrumptulescent mushroom treat into your mouth. It tastes like fungal-flavored candy. The gastronomical delight turns out to be a toadstool, and you succumb to its choking, asphyxiating aftertaste.";
   end the game in death.


>eat it
You pop the scrumptulescent mushroom treat into your mouth. It tastes like fungal-flavored candy. The gastronomical delight turns out to be a toadstool, and you succumb to its choking, asphyxiating aftertaste.



    *** You have died ***



In that game you scored 0 out of a possible 0, in 2 turns.


Would you like to RESTART, RESTORE a saved game or QUIT?
>

Yes, I know “scrumptulescent” isn't a word, but it should be. Notice how our rule uses some different punctuation than the previous rules. We use a semicolon (;) after each source command until we reach the last one, which we end in a period (.). The period means that we are finished with the rule. As a mnemonic device, it helps to call the period a “full stop” like non-Americans do. A full stop ends a rule.

Now, it's not really fair that we have such a plain, obviously edible item with only the scantest warning of its lethality. Everyone hates insta-kill plot devices. Let's give the player a sporting chance:

A mushroom is here. It is edible. "A polka-dotted mushroom pokes out of the moist soil. It is possibly scrumptious." The description is "[if we have not examined the mushroom]Upon further examination, you decide that, while possibly scrumptious, it is also possibly a toadstool. You might want to keep examining it[otherwise]Now that you look at it again, you can see clearly that it is a toadstool; a nasty looking one, at that[end if]."


>examine mushroom
Upon further examination, you decide that, while possibly scrumptious, it is also possibly a toadstool. You might want to keep examining it.

>examine mushroom
Now that you look at it again, you can see clearly that it is a toadstool; a nasty looking one, at that.

Now we have an EXAMINE description that is only used the first time we examine the object. Thereafter, we display a different one. The ability to embed conditional logic into our displayed text is a powerful tool, and one we will use often. Note the use of the square brackets ([,]) to delineate embedded conditionals, just like the font italicization in the “when play begins” rule. Also notice that I manipulated the text so that the “end if” tag comes before the period. That's so I don't have to put another period after the quote. Why? Because a full stop ends a description, too.

When I say This, I mean ThatEdit

In the example above, we revealed to the player that the mushroom is really a toadstool. However, the rest of the text of the game still refers to it as a mushroom. We can fix this with a rule and a “understand” clause, like so:

Understand "toadstool" as the mushroom;

After examining the mushroom for the second time:
   change the printed name to "toadstool".

The printed name is what is displayed when we, say, use the INVENTORY command:

>examine mushroom
Now that you look at it again, you can see clearly that it is a toadstool; a nasty looking one, at that.

>take toadstool
You deftly snap the mushroom's stalk, and pluck the hapless fungus from its natural habitat.

>inventory
You are carrying:
  a toadstool

The “understands” command means this: “from now on, treat “this” as “that.” In this case, we tell Inform to read “toadstool” as referring to the mushroom; thus the ability to use the word “toadstool” to get the mushroom.

Now, we have a problem. We know that we are looking at a toadstool, right? But we say, when taking the toadstool, that we're “deftly” snapping the mushroom's stalk. That can't be right, can it? How can we tell it to switch to toadstool when we recognize the mushroom as such? We do so by changing all instances of “mushroom” in the display text with “[printed name]”. In the rule we wrote above, the “printed name” property of the object gets changed to “toadstool” after we examine it for the second time. This means that whatever text refers to the mushroom using “[printed name]” changes as well.

SceneryEdit

We now have a very descriptive initial room. We dropped the player in a jungle, near a temple, with an entrance leading down into darkness. So, what can we reasonably expect the player to do? What if the player decides to examine the temple?

>examine temple
You can't see any such thing.

Well, of course we don't see any such thing. Just because we put it in our room description doesn't mean Inform is going to know about it. We have to create an object:

The temple is here. The description is "The stone blocks lie in a large pile, with some strewn about, worn and broken. Vines cover the upper half, while soil, leaves and grasses cover the bottom half. A set of steep stairs goes straight down into darkness."

This gives us one small problem: redundancy.

Forest
You stand in a clearing in the deep jungle. Obscured by centuries of overgrowth and dim sunlight is a ruined temple of some sort. Whatever details there may have been on the stone blocks have long since been worn away. There is a single, solitary entryway leading downward.

A polka-dotted mushroom pokes out of the moist soil. It is possibly scrumptious.

You can also see a temple here.

“You can also see a temple here” is completely superfluous in this case, because our room description already has everything we want to say about the temple at first glance. There is a way to tell Inform not to display an item with this message. We declare it as “scenery”:

The temple is here. It is scenery. The description is "The stone blocks lie tumbled about, as if they were strewn about. Vines cover the upper half, while soil, leaves and grasses cover the bottom half. A set of steep stairs goes straight down into darkness."

This fixes our previous problem with respect to displaying the temple unnecessarily when looking around. Of course, since we want people to see our snazzy new description for the temple, let's force them to examine it by hiding the secret passage until they do. We do this by changing our initial description of the room:

The Forest is a room. "You stand in a clearing in the deep jungle. Obscured by centuries of overgrowth and dim sunlight is a ruined temple of some sort. Whatever details there may have been on the stone blocks have long since been worn away[if we have examined the temple]. There is a single, solitary entryway leading downward[end if]."

If we wish, we can add more scenery for the passage, the trees, the ground, or whatever. Remember that the more you cater to a player's curiosity, the richer and more immersive your game will be.

ExplorationEdit

One room does not a game make (unless you are really good). We add a second room thusly:

The Dark Passage is a room. It is down from the Forest. "This passage is dark and cramped. This is obviously not the original entrance to the temple's underground chambers. It continues to the north. A dim shaft of light comes from the exit to the forest above."

We not only define the room, we define its relation to other rooms. In this case, the player would type DOWN or GO DOWN in the Forest to enter the Dark Passage. Inform is smart enough to make this a symmetric relationship, such that you can also go UP from the Dark Passage back to the forest. Notice that we put in our description that a room lies to the north. We're going to have to remember to put another room there.

Exercise to the reader: Make up the rest of the temple.

Treasure: A Kind of ThingEdit

Treasure is a kind of thing. It's true. In fact, treasure is a kind of thing with a value called “worth.” And unless someone gives it worth, it doesn't have any. A Spanish Doubloon is treasure, and is worth up to $1,400.

Hey, wait a sec... that looks like source text!

Treasure is a kind of thing. It has a number called worth. The worth of a treasure is usually 0.

A Spanish Doubloon is here. It is treasure with worth 1400. "A Spanish Doubloon lies glinting on the floor." The description is "This coin is marked as an eight escudo piece. That's a neat $1.4K in your wallet. [if we have not examined the Doubloon]Are there perhaps more pieces o' eight waiting for plundering?[end if]".

That was easy. Using this form, you can declare all kinds of things (I pun!). For instance, you can give objects weight, and give players strength, and compare the two any time a player tries to pick something up.

Exercise to the reader: Make sure that the player can refer to the Doubloon as a coin, gold, “bit,” or anything else you can think of.

Creating New ActionsEdit

Why is our archaeologist here? What is he here to accomplish? Let's say he's here to photograph the ruins, and all the objects therein. Let's say that, in the first room (the Jungle), he tries to photograph the temple:

>photograph temple
That's not a verb I recognise.

Apparently, Inform doesn't know what “photograph” means. We're going to have to teach it:

Photographing is an action applying to one thing. Understand "photograph [something]" as photographing.

Now we can write rules about photographing various objects in the game. For instance, using the temple in the first room:

Before photographing the temple:
   say "*click*[line break]You get a great shot of the temple ruins.";
   award 5 points.

Since this action is the objective of the game, we can award points from it.

What we have so far, though, is actually kind of lame. We have to write a rule for every object in the game we want to photograph? What happens if we don't have a rule for an object? Nothing. Let's set up a more generic rule, and have every object have a specific point value. Here's a much more robust system to replace the “before photographing the temple” rule:

Things have a number called point value. The point value of a thing is usually 0. The temple has point value 5.

Check photographing:
   if the point value of the noun is 0, say "*click*[line break]You take a picture of a totally uninteresting [printed name]." instead;
   if the point value of the noun is -1, say "You already got a picture of that." instead.

Carry out photographing:
   say "*click*[line break]You get a great shot of the [printed name].";
   award the point value of the noun points;
   change the point value of the noun to -1.

Whoah! That's a lot to take in. First, we gave everything in the game a property called “point value,” which is zero unless we specifically say otherwise. We then state that the temple (the scenery object) has a point value of 5. We actually could have put this in the temple declaration itself (“The temple is here. It is scenery having point value 5.”).

Next we “check” the action with the “check photographing” rule. A check rule is where we can stop the action or redirect it if certain prerequisites are not met. First, if the object being photographed has no point value, we do not award points, and inform the player that it was boring. Second, if the object is already photographed (a point value of -1 equating to “already photographed” is a relationship we will establish in the “carry out” rule), we tell the player that we already have a picture of the object.

Finally, the “carry out” rule defines what happens when we photograph an object with point value that has not been photographed before. We display a happy message, award a number of points equal to the object's point value, and set the object's point value to -1 (thus tripping the check rule for -1 point value if we try to photograph the same object again).

Note that in this rule, we are referring to the object as “noun.” We defined “photographing” as “an action applying to one thing.” This “thing” is represented by a noun the player has entered in the command line. In the case of photographing the temple, the “noun” is “temple.” The “[printed name]” embedded value, conveniently, always refers to the printed name property of the current “noun.”

Exercise to the reader: Give certain objects in the various game point values, which the player automatically accrues as points for taking pictures on them. Give out 30 points total. Add the line “Maximum score is 30.” near the top of the source. Now the player can track their progress in the game using the SCORE command.

Winning the GameEdit

Winning the game is as easy (from the writer's perspective) as losing the game. Let's consider a possible ending:

An ancient trophy is here. It is treasure with worth 1000000 and point value 5. "An ancient trophy lies here, discarded." The description is "This ancient trophy is worth one million dollars!"

After taking the ancient trophy:
   say "You take the trophy, a item of such worth that you can now return home, satisfied that you have properly plundered the temple!";
   end the game in victory.

In this case, we tie the winning ending to an “after taking” rule on a treasure object. In the game, this object would probably be accessible only through a series of puzzles or challenges.

It's just as simple to customize the end response, to say something such as "You return home a hero."

After taking the ancient trophy:
   say "You take the trophy, a item of such worth that you can now return home, satisfied that you have properly plundered the temple!";
   end the game saying "You return home a hero".

You can also tie victory to the player's score, if you so wished. Let's say we wanted the player to photograph all the artifacts, and then make it safely back to the forest:

Every turn when in the Forest:
if score is 30
begin;
   say "You emerge from the ruined temple, having finally taken photos of all the wonderful artifacts therein.";
   end the game in victory;
end if.

The “if...begin...end if” block is a familiar convention to programmers. Normally we would say, “if this, then do this one thing.” In this case, we're saying, “if this, then do all of these things, starting here, and ending here.” Notice the semicolons at the end of each line up until the full-stop.

Last modified on 5 July 2011, at 22:51