#inform guide

[wshiny]

I7 Extras: General Actions, Variables, Switch Case, Taking Inventory

Part 1: The Player, Objects, and Rooms. Part 2: Custom Actions and People. Part 3: Using Conversation Extensions.

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending I7 Extras: General Actions, Variables, Switch Case, Taking Inventory (You are here!) 

The next installment of I7 extras are things that are not explicitly necessary to making your game better, but it will definitely help you make your life easier (yes, this is true, and life advisers hate this one tip). Let’s get started.

Full post under read more:

General Actions

Whenever we perform an action to an object and have not pre-defined it, the player will receive the default Inform response (example, you see nothing special about X when it is examined). 

For this sample game, one of the main defining features of our player character is his relationship with perceiving the world. In the sample room, he interacts with the world by using his keen sense of smell to complete his mission. There are a few objects in the room, and we want him to have a same generic reaction to all of them that isn’t the Inform default.

Where we previously would define a custom definition for each object akin to:

Instead of smelling lamp:     say "Smells like cigarettes.  Disgusting.  [paragraph break] ... And      nostalgic.." Instead of smelling file:     say " Smells like cigarettes.  Disgusting.  [paragraph break] ... And nostalgic.."

Now we can comment out the above and use the keyword something to override the default.

Instead of smelling something:     say "Smells like cigarettes.  Disgusting.  [paragraph break] ... And nostalgic..".

Note that if you specify the action on an object that already has a generic case like the one above, Inform will use that specific one. In this case, smelling anything that isn’t a lamp.

Instead of smelling lamp:     say "Smells like burnt rubber. [paragraph break] Warm summers on the outback. [paragraph break] Clarissa."

Here we are testing smelling an object (blazer) without defining it specifically and our overridden text.

Variables

It may surprise you, but we’ve been using variables the entire time! Albeit just  booleans, other types of variables behave very similarly. Take a look at the I7 For Programmers for a full list of the different types that can be instantiated. For this demo, we’ll be using bools as a refresher and a number variable.

hasExaminedWatch is a truth state that varies. numLookedAtWatch is a number that varies.

The first being whether or not the watch has been looked at, the latter being the number of times the player has looked at the watch. By default, truth states start at false and numbers start at zero. When we look at the pocket watch, we want to set the boolean to true and increment the numLookAtWatch amount.

Instead of examining the pocket watch:     say "There are too many cracks on the glass surface to tell time.";     now hasExaminedWatch is true;     [now numLookedAtWatch is numLookedAtWatch plus two.]     increment numLookedAtWatch.

Note the commented out portion. numLookedAtWatch is numLookedAtWatch plus two is the same as saying numLookedAtWatch = numLookedAtWatch + 2.

increment numLookedAtWatch is the same as numLookedAtWatch++

Switch Case

So now you have a counter on how many times the player has looked at the watch. What if we want some reaction to happen depending on the number? We could do something akin to

 say “[if numLookedAtWatch is 1] i have done this once [else if numLookedAtWatch is 2] i have done this twise [else if]....”

But that would be time consuming and tedious. Fortunately, there are switch case statements that make this process faster. Here is a sample of combinging the boolean value with the number of times we have looked at the watch.

Instead of smelling watch: say "[if hasExaminedWatch is false] Clarissa [end if]"; if numLookedAtWatch is: -- 0: say " (sigh) "; [if we haven’t looked at it yet, say this] -- 1: say "..."; [if we looked at it once, say this, etc] -- 2: say ".........."; -- 3: say "......................"; -- 4: say "what's the point?"; -- 5: say " .................... [paragraph break] You sigh."; -- 6: say " .... "; -- otherwise: say "no matter how many times you look at it, she won't come back.";

It is important to note that this is extremely space sensitive. 

Have a space between '--' and the number (value of your case). Make sure there is no space from the end of you variable to the ':'

Taking Inventory

Giving credit to where credit is due, this is taken from Emily Short’s handy reference tools floating around on the internet. We can define what the player is carrying and wearing at the beginning of the game without explicitly defining each as an object, while treating each object as such.

[What the player is wearing] The player is wearing black trousers, a collared shirt, an old tweed blazer, plain gray socks, and a silver band. The player is carrying a gold pocket watch.

By default, the inventory mentions nothing about what the player is wearing. But we have evolved beyond that stage and have already changed the default behavior interaction with objects- so why not change how the inventory is displayed?

The syntax for the player entering i/inventory is taking inventory and the person playing the game is always referred to in the source as the player. 

Instead of taking inventory: say "[if the player carries something][We]['re] carrying [a list of things carried by the player][otherwise][We] bag is empty.";

say "[paragraph break][if the player wears something]. [We]['re] wearing [a list of things worn by the player][else] You probably shouldn't go out in your undergarments. [end if]."

Which will produce this:

Hope that was useful. The full source can be found here! 

[wshiny]

I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending

Part 1: The Player, Objects, and Rooms. Part 2: Custom Actions and People. Part 3: Using Conversation Extensions.

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals   I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending (You are here!) 

So I must apologize in advance for this example as the ending is terrible in terms of being something compelling from a narrative standpoint, but for the purposes of teaching how to code the actions it will suffice.

Take a look at this:

An actual title screen. Isn’t it beautiful? (Many thanks to Tamrah for helping me realize that this existed and putting together a title layout).  As always, full post under read more:

Basic Screen Effects

We will be using the extension called “Basic Screen Effects” by Emily Short in this demonstration, which is one of the built-in Inform extensions. If you have taken a look at the previous Extras example, you will notice that I have been using that in minor places (carrying out the custom sighing action by allowing the player to press a key before continuing to print out text).

As with all extensions, we must first include this in our source with Include Basic Screen Effects by Emily Short. 

*Please note that this extension is not completely functional. For our purposes for the extension (creating a title screen and pausing the game/other pacing-based screen effects), it is fine but if you look at the Inform documentation it supposedly also does text and background colors. This is not the case anymore (Inform will not recognize anything to do with colors). 

Never mind that, we can still have a pleasant experience. Let’s take a more in-depth look at how to use it with a custom action:

Laughing is an action applying to nothing. Understand "laugh" and "chuckle" as laughing. Carry out laughing: say "You don’t have the luxury of laughing. [paragraph break]"; wait for any key; [This is from our extension! it lets us take a breather] say "You know the world has hideous, horrible things hiding in the shadows".

[That quote is taken from MonsterHearts by Buried Without Ceremony. It's one of my favorite tabletop role-playing games!]

Here when we use wait for any key, Inform will allow the player to press any key before continuing with the story. This is a good way to break down strings as well, and affect the player’s experience with how much information you are giving them at once. 

Title Screen

Most of the title screen syntax is from the extension. We are using when play begins to define information prior to printing the banner (Story title by author, serial number and etc) and clearing the screen to remove prior information if necessary. 

Centering something, by default, will print out the string in a different text. The default type that most of the story is in is Roman type, so if it feels too inconsistent, precede the strings with [roman type] .

Pausing the game is an action defined by the extension and will disallow any key other than SPACE to be pressed in order to resume.

When play begins: clear the screen; center "[story title]";  [Use Roman type to change the font to default] center "[story author]"; say paragraph break; say paragraph break; say "It's not safe here. Don't laugh. Don't dream. "; pause the game. [Will print out Please press SPACE to continue]

Now, this is all fine and dandy, and after the SPACE is pressed the game resumes as usual.

But you see that Release 1/Serial number information? And information about the title and author, that we just got in the previous screen? That’s not completely necessary for our purposes so feel free to remove it with a rule. This group of information is called the banner text, so if you want to learn more about altering it, that is the key word to look up.

[Remove that banner text if we don't want it to break our flow.] Rule for printing the banner text: say "[italic type]You sense a presence- strange, but also familiar. You try to remember what this may be, but you forget. [paragraph break]You always do." instead.

There- much better.  

Repeat Every Turn

If you want a particular action to occur after every turn (a turn is counted for every input that a player makes and presses the return key), such as  creating suspense or reminding the player or something, then every turn may be what you’re looking for. Plus, it counts as a separate string so that is another way to sneak words into your game. 

In this particular example, the player has the ability to dream at any time, which is a custom action. After the first dream, a bool is set to true. After the player has dreamed once, I want a line of text to keep appearing no matter what the player does, so this is an excellent way of showing that.

every turn: if didIDream is true begin; say "You can't shake off the feeling that you're being watched."; end if;

Ending

There are a few ways to end the game, and it is entirely possible to have multiple endings. We can use end the story, end the story finally, end the story saying X, or end the story finally saying X. 

Finally implies that this is a “good” ending, although there are very minor differences and can be used interchangeably. When we use end the story or end the story finally, the ending text will be ***THE END***. If we want to change what the text is between those  asterisks, it is better to use the saying X portion and whatever string is in X will be displayed as ***X***.

Instead of drinking the bottle: say "That's not water. [paragraph break]"; end the story saying "It's poison."

After eating the glowing orb: say "Your mind begins to feel fuzzy [paragraph break] Your vision blurs"; end the story.

Since we have explicitly stated Use no Scoring in the rules section, there will be nothing related to a score. But if we did not, then Inform is able to print that information out to rate the performance of the player throughout that run.

The full source can be found here. 

[wshiny]

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals

Part 1: The Player, Objects, and Rooms. Part 2: Custom Actions and People. Part 3: Using Conversation Extensions. 

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals  (You are here!)  I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending 

Hey all, some people have been wondering how to properly implement doors and how the heck if statements worked in Inform when not in the context of a string, so here’s a handy dandy explanation for them. As always, consult the Inform handbook and main website for more details but here’s a general overview to them. I will also go over how to add more exposition your starting scene and change the behavior of default commands (more specifically, the take all actions.

Full post under read more.

Exposition

Now look at that beautiful exposition. See how there’s a line of text before the default generated Title/Author/Release info and all that? But wait- you say, I’ve seen that before in your previous guide. That’s when play begins. 

Right you are, anonymous stranger on the internet. Right you are. But notice how there is further text before the starting room (Gym)? Sometimes you don’t want to jump directly to starting the game after the title information. Sometimes you want a little extra, and that can be accomplished by after printing the banner text. 

[All text of When play begins start before the title] When play begins: say "This is a demonstration of how to do cool extras using Inform 7! I hope you learn something worthwhile."

[All further introductory text, before the description of the starting room, is below: ] After printing the banner text  : say "[paragraph break][bold type] RIIIIINGGGG! [roman type] Saved by the bell, right as your teacher asked you to do an extra lap around the perimeter of the gymnasium. [paragraph break]"

Alright sweet, now what’s this overriding action thing about?

Overriding Default Actions

In the previous game I’ve worked on, I created over fifty items that could be picked up from a single room (pencils of varying colors, erasers, random stationary and even dust bunnies) and the player could easily pick up all of them without examining every one first with the “take all” action. Perhaps this is a niche issue, but for anyone who want items go be discovered and safe from take all, there are two main methods of doing so.

The first one, is to have all items that should not be revealed in a separate location called Space, similar to the Supporter/Container example. The downside to this approach is keeping track of every single item. 

The other one, is to override the default action of “taking,” as you cannot directly address “take all” by its own action as its a child of “take”. By redefining “take,” with Understand the command (X) as something new, we can declare its rules, and as long as we do not define a general definition for “take all” while adding all the functionality of “take,” that would not become an issue. That might have been a tad difficult to read, so take this example instead showing the most common uses of the take command:

Understand the commands "take","carry" and "hold" as something new.

Understand "take [thing]" as taking. Understand "take off [thing]" as taking off. Understand "take [thing] from [thing]" as removing it from. Understand "take [thing] off [thing]" as removing it from. Understand "take inventory" as taking inventory. Understand the commands "carry" and "hold" as "take".

Doors

There’s a lot that can be done with doors- the classic lock and key puzzle, requiring an object or action before the player can move from one location to another. Let’s take a look on how to implement a simple puzzle of requiring the player to open a door before allowing them to enter the adjacent room.

[This is how to make a door!] The double doors is an undescribed door. [This describes what the connecting rooms are. It does not particularly matter what is the "outside" and "inside" room in this case.] It is outside from the Gym and inside from the Hallway. Understand "doors" and "door" as double doors. The double doors is closed.

If we allow the doors to be described, then that would appear in the same line as any other object in the room. However, since we already mentioned that they exist in the description, we will avoid repeating any unnecessary information.

Now- this doesn’t do anything so far. While Inform recognizes that door is a thing that can be opened or closed, a door doesn’t exactly keep you constrained as players can easily move to another room.

This part is a little tricky- Instead of going to X does not work by ridiculous Inform logic as you are interrupting a core process (of changing rooms), and Before going to X does not produce the intended result- the player still goes to the connected room afterwards. What we can do is use the keyword after to denote an action immediately after Inform transitions to the designated room.

Of course, this doesn’t prevent the player from going in the room at all. But- the player, that is, the person playing the game does not know that since we remove any text that is related to going to the designated room and immediately place the player back in their original room.  

In the section below, we will allow the player to move from the starting position (Gym) to destination (Hallway), then immediately move player to Gym; if the doors were closed. If the doors were open, we can proceed to move the player to the Hallway.

Standalone If Conditionals 

The term standalone may be misleading- what it really represents are if statements that do not fall within a string. If statements follow a certain structure. 

After going to Hallway: if double doors are open begin; move player to Hallway; otherwise; say "[one of] You're not a ghost and you can't phase through walls. Why not try opening the  door? [or] You're still not a ghost. [stopping]"; move player to Gym; end if;

Note the syntax. The first condition is a colon, and the rest, even to the end of the if statement, are semicolons. This is different than the standard usage of a period punctuation to signify the end of a statement that has been previously explained.

if (X == Y) begin; else if; otherwise; end if;

Of course, you are going to want to have this statement functioning for the other direction too (heading from Hallway to Gym), but that’s it! Hope something was useful.

You can find the full source here  with extra tidbits (another example of overriding actions and allowing player input between strings) minor revisions. 

[wshiny]

I7 Guide Part 3: Using Conversation Extensions

Part 1: The Player, Objects, and Rooms.  Part 2: Custom Actions and People.  Part 3: Using Conversation Extensions. (You are here!)

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals  I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending

By this point, you should have a solid understanding of how to interact with objects and people across multiple environments. Please get started with the Conversation Example Start file in NYU Classes if you haven’t done so already! 

In this .inform, we have a situation similar to the finished example from part 2, where there are objects and rooms for the player to interact with, as well as user-defined actions and people. 

There is something new though! If you play around, you might notice some text above the header that wasn’t there before.

Wait what? How can you have text before the title? For exposition and narrative framing (still subject to the character limit, I’m afraid) of your piece, you can write some text that only appears as soon as the file is launched. This is called when play begins. In addition, you can modify the type text to italics by declaring [italic type], bold with [bold type], and default with [roman type]. 

When play begins: say "[italic type] As you enter the tavern through the hardwooden door, you're welcomed by an eerie silence and the smell of alcohol. The bartender is pouring a drink for a customer and makes no effort to acknowledge your presence.  [paragraph break] The sharp [roman type]click [italic type] of the door locking behind you brings a chill up your spine. [roman type][paragraph break]"

*Yes, I realize I spelled presence wrong.

So what now? For this example, we will be using Conversation Framework by Eric Eve to demonstrate how to install and use extensions, as well as keywords for this sample.

Full post under read more.

First of all, Inform has many extensions installed by default and you are permitted to use them for the assignment. That being said, it’s best to install something through the public library- as other methods of installation can be faulty (especially for windows, as fellow peers over at intfiction have discovered). 

But how do we install the extension we want? If you look on the tabs under the Go, Replay, and Release buttons, you will see a header of Source/Results/Index/Skein/etc. 

Click on Extensions, which will show three more tabs- the home icon, definitions, and public library. Click on public library. There, you can see all of the extensions available and fully supported by Inform (to my knowledge, only fully functional extensions are featured there, so there is no risk of downloading a piece of code with compiler errors). Go down to Fancy Symbol #6, Other Characters, and just hit the big ol’ INSTALL button on the first one.

Alright, now we’re installed. How do we actually use this extension, though? We can include it at the top of the .inform source. The syntax is Include [extension name] by [author]. Note that the extension name should be as it appears in the installations library, without the version.

Include Conversation Framework by Eric Eve.

Fantastic. Immediately, if we comment out all of the dialogue and custom actions, you’ll note that we can still talk to the bartender NPC! This is because the extension already has these actions pre-defined in the package. Beforehand, we had to declare TALKING TO as an action, but now you can just say hello and there is a response.

Now, with all things, it would not be very interesting if all of the NPCs in your work had the same default responses to everything. Note that with extensions, they may use different syntax for instead/before statements, as such:

After saying hello to bartender: say "[one of] You greet the bartender. He looks up from his work and there is a loud, suffocating silence as he stares at you before bringing his head back down.  [paragraph break] '...' [paragraph break] '...' [paragraph break]'Welcome.' [or] You greet the bartender. He hums quietly, lifting a glass and inspecting it for specks of dust. When satisfied, he nods to himself and places the glass down in the clean pile.

[or] He nods in acknowledgement. [stopping]".

We don’t use “instead of saying hello to bartender.” In this extension, the keyword is after. There are two major points of interaction that you will probably use for your mystery to gather clues and information asking and showing/telling.

One thing Lost Pig does really well is give a list of possible conversation topics to talk about. If players are ever without a sense of how to progress though the story, then prompt them with clues and hints through that system. (”You could talk about X/Y/Z”.)

[You can TELL people ABOUT things, and change what they say, like so: ] After informing bartender about the note: say "He shrugs and continues to wipe down some glasses with a used washcloth. [paragraph break] '...'". [You can ASK people ABOUT things] [ ITS QUIZZING. QUIZZING. ] After quizzing bartender about the note: say "He shakes his head."

The syntax is a little strange, but telling is equivalent to showing and asking is equivalent to quizzing. You can see the full list of verbs that come with the extension if you return back to the home page and view the extension there. Clicking on the title will bring you to some of the documentation.

To wrap things up, there are also two types of speech- implicit and explicit. An example of implicit is typing “say hello to,” and an example of explicit is typing “hello.” The character may respond differently depending on your writing/playing style. Here’s a splendid sample from the documentation:

 After saying hello to Fred when the greeting type is explicit:    say "'Hi, there, Fred old fellow!' you exclaim.        'Well, hello there!' he grins."    After saying hello to Fred when the greeting type is implicit:    say "Fred looks up when you speak."

That’s it! If you have any particular requests for how to do something, feel free to shoot a message or e-mail. The full version can be found in Resources as Conversation Example Finished, or here with minor revisions. Thanks guys~

[wshiny]

I7 Guide Part 2: Custom Actions and People

Part 1: The Player, Objects, and Rooms.  Part 2: Custom Actions and People. (You are here!) Part 3: Using Conversation Extensions. 

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending

So now that we understand how to create a basic space to navigate, interact with the inventory, and change basic actions for our own possibly nefarious purposes, what’s next?

What if we want to create a custom action that inform does not have? If we want to do something akin to stare at X, shake fist menacingly at X, or do a little dance, there’s no way Inform will let us get away with those shenanigans without defining a custom action. In addition, here we will go over the basic information about creating an NPC to interact with. 

Full post under read more.

If you’ll download the example called Person Example on NYU Classes, there’s already a sample room set up. Go ahead and try interacting with the environment, nothing fancy from what we did not do in the previous example. 

Note that we can what happens when we examine ourselves! ('x’ is short for examine). That’s easily done by defining the description for the player. 

Now, there’s three things we will cover: Actions to self, actions to others, and NPCs. Let’s start with the first one.

Remember how we defined Chapter in the previous tutorial and marked that as primarily a way to organize our code? Inform also recognizes Sections, so we can use that to easily break apart our Rules and actions. This is not strictly necessary, but is great for a clean source file. 

In this story, we are an attendant in a ballroom who feels out of place. One of the actions that may be relevant is sighing - by default, we can type “sigh” and nothing will happen, because Inform doesn’t recognize our social distress. We can define what “sigh” is, and what “sighing” does, with a custom action.

Section 1 Self Actions

Sighing is an action applying to nothing. [Applying to says you don't need an object or a person to do the sighing action to] Understand "sigh" as sighing. [Now this is how you use it:] Carry out sighing: say "Your shoulders slump forward as a breathy sigh escapes your lips.".

Actions are made with X is an action applying to nothing. Note the comments that help explain what they do. Try it out.

Note that when you create an action that applies to nothing, the syntax is Carry out. 

Why did I stress this? Because when you have an actions that apply to others (you need one other object when using the action, like talk to, dance to, wave to, etc) Carry out no longer works, instead, when you create an action that applies to at least one thing, we use Check.

Greeting is an action applying to one thing. Understand "greet [someone]","say hi to [someone]", "wave at [someone]" and "wave to [someone]" as greeting. Check greeting: say "[noun] scrunches their nose in distaste."

Note that when you Understand, the person you talk to is [someone] and when you do Check, the person you talk to is [noun]. Classic Inform. 

Why only greet people, when you can talk to them too? We’re going to have to define another custom action to do that, since Inform does not recognize talking to. 

[Talk to people!] Talking to is an action applying to one visible thing. Understand "talk to [someone]" or "converse with [someone]" as talking to. Check talking to: say "[noun] is not interested in speaking or even interacting with someone of your status". [Ouch.]

Wow, these people sure are jerks, whoever they are.  But who are these people? A valid question since we don’t have anyone to talk to right now. Let’s make someone who is a little less of a jerk. The syntax for that is X is a person in Room. Just like objects, people must be created in rooms. Everything must be created in a Room/exist in a space. 

People can wear clothing, too! Here we see our sample NPC, Helen, wearing an item. When we try to take the item, we are not permitted to do so (shown in the image below). 

[A npc approaches==========================] [This is how you make an NPC: X is a person in (Room)] Helen is a person in Ballroom. [They can wear clothing, too] Helen is wearing a beautiful ball gown. Understand "gown", "dress", and "ball gown" as beautiful ball gown.

[When the player first sees helen:] Understand "lady" and "woman" as Helen. The initial appearance of  Helen is "A beautiful woman sits on a chair by one of the tables, her gaze switching between scrutinizing you and the dancers". The description of Helen is "Also out of place, but much less so than you".

As you can see, People are no different than Objects in terms of description, defining appearance, and interacting with (you can most definitely attempt to take/taste/smell/etc a person, but they will likely have a noncommittal response). This makes them easy to make.

What about these dancers that Helen is talking about? What if the player tries to examine the dancers, believing them to be some undescribed people and feeling frustrated with the fact that the context is giving you clues that are not there? 

There are multiple ways to create groups of people, but one way is to use a collective name (dancers) as a single person (always refer to them as plural to the player). 

[Let's make some dancers- how to make groups of people] some dancers is an undescribed person in Ballroom. Understand "dancers" and "the dancers" as some dancers. The description of some dancers is "Colorful bodies moving in unision throughout the room to a classical melody."

Now, that’s all you need to know for how to interact with a person. We can even update our talking to and greet, so that when we perform those actions on Helen or some dancers, they behave differently.

Check greeting: say "[if noun is Helen] Her lips part as if to say something in response, but they do not. [else] scrunches their nose in distaste."

Check talking to: say " [if noun is Helen] 'Helen. It's Helen, if you must ask... and yours?' [paragraph break] She is looking down and crossing her arms.[else] They look at you with a mirthful mockery and chuckle quite audibly before returning to their neverending waltz.".

Note that we do not need to explicitly define[if noun is dancers] because we only have two characters here, and can shove them in the else statement. Now, there is an alternative checking every single talking to statement in that one string, because if you have multiple characters that have different talking to statements, it can become an indecipherable mess. 

Just like regular actions, custom actions can also be altered at any point in time with Before and Instead. Here is an example of overriding the default Check talking to and being more detailed with interacting with Helen.

KnowHelensName is a truth state that varies.

Instead of talking to Helen: say "[if KnowHelensName is false] Helen. It's Helen, if you must ask... and yours?' [paragraph break] She is looking down and crossing her arms. [else ] 'There are plenty of other dancers here tonight'"; now KnowHelensName is True.

And that’s it! You can find the full version under Person Example Finished, or right here (with some minor changes). 

[wshiny]

I7 Guide Part 1: The Player, Objects, and Rooms.

Part 1: The Player, Objects, and Rooms. (You are here!) Part 2: Custom Actions and People.  Part 3: Using Conversation Extensions. 

I7 Extras: Exposition, Overriding Default Actions, Doors, and Standalone If Conditionals I7 Extras: Basic Screen Effects, Title Screen, Repeat Every Turn, Ending

What? I know what you’re thinking- there are tons of tutorials and resources online! What is another one doing here? Well, these are primarily used as refreshers for my students, and I’m putting them online for anyone to needs it and/or cannot find other resources. So there. Totally valid.  

And without further ado! This post will explain the basics of how to get started with interacting with the player, creating and defining items, and moving around rooms.  

Full post under read more!

Our first adventure! First, let’s tell Inform that we are making a Story with Part-Story. and Chapter 1. Inform will automatically bold these as it recognizes them as keywords. The Parts and Chapters are a way for you, the writer, to organize your words and are optional.  This sweet syntax [ ] is how you make a comment. Comments are the best, because they allow you to write notes to yourself without having the interpreter recognize it as something to compile. Anything that goes inside the square brackets will be ignored as long as it is not in a quote (worry not, it shall be explained in due time). This also works for multi-line comments! 

“Sample Adventure” by Me Yay

[This is how you make a comment.]

Part - Story

Chapter 1

Now, let’s get a setting. How about a forest clearing? In Inform language, Regions are things that hold Rooms, and Rooms are primarily areas for players move through. We can define the forest as a region with BigForest is a region. They are optional, so what’s the advantage to having them?

Scenery text! A backdrop is something that can be attached to a region and persistent throughout the entirety of rooms that are associated with said region (and they can be moved if necessary). Here is how you make a backdrop:

[Regions are things that hold rooms] BigForest is a region. 

[A backdrop is a scenery. IT  can be moved or static] Some trees are a backdrop in BigForest. The printed name of Trees are "trees in the forest".

Whoa wait, what is printed name? I’m glad you asked, it’s what the player sees when going through the game. Your variable, “trees”, will show up with its variable name. If you named it “_trees” or “bd_trees”, that’s what the player will see. We don’t want that, so printed name covers up the variable name and shows up differently to the player. Note, though, that the code will still only recognize Trees by its variable name. Also note that this is not case sensitive.

If you try to compile this, it will not run. But why? It’s because the player does not have a room to start one. So let’s make one called Clearing.You can define rooms by saying X is a room, or X is a room in Y, where Y is the region.

You can also give rooms descriptions, which is the text that shows up whenever a player looks around or enters a room. 

Clearing is a room in BigForest. [Let's write a description for clearing] The description of Clearing is "There are many trees in the clearing. To the south, there is a small path. The other directions are surrounded by trees and they are so dense that you cannot cross.

Now, when we run our code, we start out in Clearing! 

However, this isn’t very interesting. We have a player in a single room and nothing to interact with. Let’s fix that right now by making some random pieces of wood lying around- a stick, and a plank. We create objects by saying X is an object, or X is an object in Y, where Y is a room that the object exists in. 

A stick is an object in Clearing. The printed name of a stick is "wooden stick". Understand "wood" and "wooden" as a stick.

A piece of wood is an object in Clearing. The description of a piece of wood is "a small plank."

What is the purpose of Understand? It can be frustrating for players if, for example, you are interacting with a variable called “a gargantuan polar bear with a voracious appetite.” Sure, it may be hilarious typing it out the first two times, but after a while the player  doesn’t want to bother, and may just want to type “bear” or “hungry bear.” the Understand keyword allows you to do just that.   

What about description? It’s the text that shows when the player interacts with the objects by examining it. If the player was to type x plank, or examine plank, the description of “a small plank’ would appear. 

So now we have a room with some objects. What if we wanted to do something interesting like create another room? That’s fine, let’s do one now:

[Make another room] Path is a room in BigForest. Path is south of Clearing. The description of Path is "a small, dirty path.".

It’s important to mention where Path is in relation to the room the player starts in (always the first defined room), so that the player can travel to Path.

Now, what if we wanted to do something even more interesting like eating the stick? Perhaps it is a delicious stick, and who are we to deny the player some much needed digital mastication?

By putting in the following line, we can make items able to be eaten:

The stick is edible. The description of stick is "A crummy piece of wood. Looks edible.".

What happens when you try eating it? The default description for eating anything, really. If we want to change the custom action we can either use the keyword before or instead. Before is generally used before Inform recognizes carrying out an action, and Instead is used after Inform recognizes the action, and does it instead of its usual carrying out. As a general rule of thumb, from transitioning from Version 6 to Version 7, instead is better to use. 

In addition, what if we want a description to change depending on some condition? For example, if you smell a stick for the first time and second time, the description changes? There’s multiple ways to do this, but one method is using a bool, implemented as X is a truth state that varies. Here’s an example:

IsStickSmelled is a truth state that varies.

Instead of smelling a stick: say "[if IsStickSmelled is true] It still smells delicious. [else] Wow! It smells delicious."; now IsStickSmelled is true.

Before eating a stick: say "The stick actually tastes really bad. Blah!";

Syntax Tip: When you start a conditional, it ends with a colon (:) and the following ends with a period (.). However, when you want to include more than one line of information, have a semicolon (;) to separate it. You can have as many semicolons as possible, but you must note that the last closing statement needs to end with a period. 

Alright, but what if we want more than just a bool to dictate our description? What if we want an item to look different every time we see it in the room? We can use the initial appearance keyword. 

The initial appearance of X is what the object looks like when the player enters the room that it is in. The description of X is what the player gets after examining the object X. 

The initial appearance of a stick is "[one of] A small chunk of wood rests at your feet. [or] The chunk of wood is still there. [or] The chunk of wood is still there. Again. [stopping]".

One of, or, stopping is incredibly useful for bypassing the character limit. The first time you see the description, it will say the first string, like so:

 The second time, it will say the second string. Here we can see the player has moved to another room, the Path, then back to the Clearing where the stick is defined.

The third time, you will get the final one, and anything after that will default to the  final sentence. It’s a good way to show progression without a chunk of text. 

Now...what’s this box business and why does it look like it’s part of the description, not the objects that are lying around?

That’s because it is! But we can still interact with the box, because it is a hidden object. Here’s how you make one:

Box is a undescribed closed openable container in Clearing. Some dirt is an object inside Box.

New syntax! What does this mean?

undescribed: Hidden. An object that’s undescribed does not show up with its initial appearance or printed name in the room that it is in.  container: Containers are a type of Object that can hold things. Some dirt is an example of an item inside the container, Box. openable: Not all containers act like a box! Think about a pitcher, you can put things in there but cannot close it. By having this keyword, you are describing the container as something that can open or close.  closed: Is the state of the container, if it is openable. We could have an openable open box (a box that is open). Instead, we have a closed box. Extra note: You can move items to the player (outside of the take X) with move X to player. That’s it! 

The entire code snippet can be found on NYU Classes as Sample Adventure (under Inform/Resources), or on this snippet.