Jake the Frustrated Noob Programmer

“Jake the Frustrated Noob Programmer” by Jake Johnson

The Forum is a room. “[if unvisited]The Interactive Fiction Community Forum[end if][if visited]It’s a forum. Yup.[end if]”

A programmer is a kind of person. A programmer can be noob or pro. Programmers are usually pro.
A person can be frustrated or calm. People are usually calm.
Jake is a frustrated noob programmer. Jake is in the Forum.

After asking Jake about “Inform 7”, say “‘I tried this program yesterday, and my muse hit me with inspiration. Before I sat down to use it, I had no idea why I stopped after trying a year or two ago. After five minutes, I remembered.’”

After asking Jake about “code”, say “‘Oh, this? I’m just showing off the very little I’ve learned in perusing the manual.’”

After asking Jake about “problems”, say "'There have been many and will be many more, but I’ll list those that I can best learn from if someone shows me how to do them correctly.

Firstly, I can’t make an automatic lantern. As in, I can’t make a device which is lit if it is switched on.

Next, I need a door to become unlocked after a conversation (or, rather, ‘tell character about object’) without a key being involved, and Inform unhelpfully responds to the verbs ‘open’ and ‘unlock’ with a giant shrug and an error message.

Third, if statements. These are the magnets to my Insane Clown Posse. No matter how I punctuate them, what I say, or what conditions I give, Inform never understands me.

Lastly, though I see it in the manual, I cannot convince Inform to remove anything from play. ‘Remove x from play’ gets nothing but an error message, likely because it’s a part of my if statements.

Can you help me?’"

After asking Jake asks about “Inform 7”, say “LOL. I think all posts should be framed this way.”

  1. For a lantern, you need to do something like this:

[code]brass lantern is a device. brass lantern is switched off and unlit. [Devices are things that can be switched on and off.]

After switching on lantern:
say “You turn on the lantern, which burns with a clear yellow light.”;
now lantern is switched on;
now lantern is lit;

After switching off lantern:
say “You turn the lantern off, and it gutters into darkness.”;
now lantern is switched off;
now lantern is unlit.

Instead of burning lantern: try switching on lantern. [This means that >LIGHT LANTERN will also work.]
[/code]

You need to use the phrase ‘now’, like so:

now the Important Door is unlocked;
now the Important Door is open;

There are two ways of phrasing if statements in I7, and they can’t be mixed together. You can use both ways within a single game, but not in the same piece of code. They’re both described in the manual at 11.7. To be more specific about what your problem is, I’d need to see your code.

That should work, assuming you put a semicolon after it, so I assume that this will be fixed by fixing your if statements.

Your solutions worked! Thanks a bunch.
Now, new problem:

I need a Balloon which goes up and down but doesn’t travel in any other direction. I tried making a rule saying that it couldn’t move in any direction but up or down, but I was unsuccessful. Then, I tried brute force, coding Instead phrases for every direction the player could move in but up or down. Inform accepted the code without any error messages, but ignored it completely.

So, to paraphrase:

Location 0 is a room. Location 1 is a room. Location 2 is a room. Location 3 is a room. Location 4 is a room. Location 2 is above Location 1. Location 3 is west of Location 1. Location 4 is north of Location 1. Location 0 is south of Location 1. Instead of going up, say "You don't have wings." The Balloon is a vehicle. The Balloon is in Location 1.

What must be plugged in to cause the Balloon to move up and down between Locations 1 and 2 but not west, north, south, or nowhere?

Check section 7.14 of the documentation; for the general solution, you want to talk about “going by the balloon.” Something like this might work:

Check going by the balloon: if the noun is not up and the noun is not down; [in this case the "noun" is the direction] say "The balloon can only go up and down." instead.

Thank you.

Great. If statements are much less mystical now. I can even get things to happen in the game.
So, next problem:

I want to make an if statement or rule (either one would work, I think) with multiple conditions. The player must be in a certain location for the first time and they must be carrying an object.

“If the player is carrying the object:”
“If the player is in the room:”
“If the room is unvisited:”

None appear to work, regardless of punctuation.

[code]The Cloakroom is a room. “You are in the cloakroom. A door leads north.”

The Theater is north of the Cloakroom. “You’re in the theater. A door leads back to the south.”

The cloak is a wearable object in the Cloakroom. “A cloak lies discarded on the floor.”

After going to the Theater for the first time:
If the player has the cloak:
say “Congratulations for bringing cloak out of the cloak room!”;
continue the action.[/code]

Alternatively,

After going to the Theater: If the player has the cloak and the location is unvisited: say "Congratulations for bringing cloak out of the cloak room!"; continue the action.

Perfect. In fact, I think I’m competent at this now. To the next level of problem!

Here’s an idea I was bouncing around and I’m trying to think of how to code it.

  1. Switching is an action. The player can switch between one of a handful of characters.
  2. When the player switches to a character, he becomes that character and takes possession of everything they were carrying. When a player switches to another character, the character he switched to comes back into play wherever the player left them and their possessions return to them.
  3. Switching works even if both the player and their target are in the same room.
  4. Switching is the result of a command and not a specific in-game event, like
After taking the chair, move the player to the Cloakroom.

This topic comes up over and over on these forums. Sorry, I don’t know the canonical thread to point you at, but here’s a somewhat interesting (if technically unhelpful) one on the same topic: Recommendations: switch-around-protagonist games - #9 by LuteinHawthorne

Here’s a more useful one: Conditional locale descs with multiple player characters

[code]Switching to is an action applying to one thing. Understand “switch to [a person]” as switching to.

Carry out switching to Mr Darcy:
now the player is Mr Darcy.[/code]

Thank you very much.

Whenever you want to look for ‘how do I do this?’ sort of things, the best place to look is the documentation in the Recipe Book. So, let’s see: we have a section called The Viewpoint Character, and under that there’s a section called Viewpoint. In addition to a lot of other useful stuff, this lists the phrase as:

change the player to PersonName;

A word of warning: this is a well-established design idea, but it’s still used rarely because it entails a great deal of extra work; making descriptions vary depending on viewpoint, that sort of thing. Most games that switch between characters restrict when the player can do this, or carry it out at pre-determined times whether the player wants to or not.

But let’s assume that you’re okay with that. Now you need a new action that lets the player switch between players. (If you’re not familiar with how to make new actions yet, the documentation on how to do this starts at chapter 12.7.)

The tricky bit about this action is that it can act on characters who are out of the player’s sight. (Normally you can’t do anything to objects that you can’t see.) So we need to mess around with deciding the scope. This is explained in more detail at 17.27, but here’s how to make the object work;

[code]A person can be playable or unplayable. A person is usually unplayable. yourself is playable.

After deciding the scope of the player while switching to:
repeat with N running through the list of playable characters begin:
place N in scope;
end repeat;[/code]

To switch back, you’ll need to do something likeJohn is a man in the Cloakroom. The player is John. Carry out switching to John: say "You feel like yourself again!"; now the player is John.
@maga: Is there a difference between “now the player is Mr Darcy” and “change the player to Mr Darcy”?

WI 8.1 suggests that “change [the variable] to [value]” is deprecated and soon to be removed from the language. So there’s that.

Yep. It was just written that way in the example I checked beforehand.

I am by no means an expert in I7 so there are probably much better ways to do it, but here’s how I did switching in my Day of the Tentacle textlation (a word I just made up to mean “translation of an existing graphical adventure game to IF format”):

[code]Rule for constructing the status line:
Fill status bar with Table of status line construction;
rule succeeds.

Table of status line construction
left central right
“[location]” “Controlling: [current character]” “”

Character is a kind of value. Characters are Bernard, Hoagie and Laverne. A character can be available or prohibited. A character is usually prohibited. Bernard is available.

Current character is a character that varies.

Switching to is an action applying to one character. Understand “switch to [a character]” as switching to.

Check switching to:
If the character understood is the current character, say “You’re already in control of [the character understood].” instead;
If the character understood is prohibited, say “You can’t control [the character understood] yet!” instead.

Carry out switching to:
if the current character is Bernard:
now everything carried by the player is in Bernard’s void;
now Bernard’s location is the location of the player;
otherwise if the current character is Hoagie:
now everything carried by the player is in Hoagie’s void;
now Hoagie’s location is the location of the player;
otherwise if the current character is Laverne:
now everything carried by the player is in Laverne’s void;
now Laverne’s location is the location of the player;
now the current character is the character understood;
say “You’re now in control of [the character understood].”;
if the current character is Bernard:
move the player to Bernard’s location;
now the player carries everything in Bernard’s void;
otherwise if the current character is Hoagie:
move the player to Hoagie’s location;
now the player carries everything in Hoagie’s void;
otherwise if the current character is Laverne:
move the player to Laverne’s location;
now the player carries everything in Laverne’s void.

Bernard’s location is a room that varies. Hoagie’s location is a room that varies. Laverne’s location is a room that varies. Bernard’s location is the lobby. Hoagie’s location is thya-outside. Laverne’s location is thfy-outside.

Bernard’s void is a container. Hoagie’s void is a container. Laverne’s void is a container.[/code]

In retrospect I did this before I found out you could just say “now the player is whoever” so this is probably a really convoluted way of doing it, but it works!

Alright, then. Easier problem:
I’ve created new directions. Up the path, down the path, behind and around, and left and right. I looked up directions and defined them properly, placing them as opposites. That part of the code I7 has no issue with.

The problem arises here:
This Location is right of That Location.
“It seems as though you’re saying that two things are the same, and I don’t understand what ‘right of That Location’ is.”

The exact coding for the directions is

Down the path is a direction. The opposite of down the path is up the path. Behind is a direction. The opposite of behind is around. Left is a direction. The opposite of left is right.
What happened?

I think this is called out in the documentation; it’s because the compiler thinks you might have a location called “South of House” or whatever. So it suggests you write “Right of That Location is This Location.” Does that fix it? (I haven’t tried it yet.)

No, it doesn’t, I’m afraid.

Looks like you’ve stumbled on a bug where directions’ opposites are created as things. If you could file a report on the Inform website, that would be great. As for working around the problem (and also bug 794), you’ll need to be more verbose:

Down the path is a direction. Up the path is a direction. The opposite of down the path is up the path. The opposite of up the path is down the path. Behind is a direction. Around is a direction. The opposite of behind is around. The opposite of around is behind. Left is a direction. Right is a direction. The opposite of left is right. The opposite of right is left. Foo is a room. Right from foo is bar.