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.
Click the "Run" button. The right-hand pane switches to the "Game" button. Try some various English-language commands:
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:
This single line in the source introduces a host of new options for the player:
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):
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:
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:
Notice that we create rules to override the default messages for these commands. Let create another, more complex rule for the mushroom:
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:
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:
The printed name is what is displayed when we, say, use the INVENTORY command:
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.
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?
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:
This gives us one small problem: redundancy.
“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”:
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:
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.
One room does not a game make (unless you are really good). We add a second room thusly:
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,500.
Hey, wait a sec... that looks like source text!
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:
Apparently, Inform doesn't know what “photograph” means. We're going to have to teach it:
Now we can write rules about photographing various objects in the game. For instance, using the temple in the first room:
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:
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:
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."
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:
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.