Putting an object in a wall?

Hi I am just starting out with Inform 7 and I have no idea how I get this done.

I want to have a an object (a brown brick) in the south wall of a room. It is supposed to be removable with another object (a scalpel).

Do I create a wall that is a container and make it a fixed object? The line “The south wall is a container. The brown brick is in south wall.” doesn’t seem to work. At least south wall is not showing up int he room description. I have no idea how to do the removing part. If someone could help me out here it would help a lot. Once I know how I make this work a lot of my planned stuff should become way easier.

There is a brick in the dungeon. Instead of taking the brick when the player does not have the scalpel, say “You have no way to pry it free.”
Rule for writing a paragraph about the brick when the brick is not handled: now the brick is mentioned.

Every once in a while, I forget how to keep things clean and simple. Nice job, Draconis – I probably would have done something much more fiddly.

I don’t think that will work if the player tries ‘remove brick from wall’ or ‘take brick from wall’.

True. You could use this in that case.

A wall is a scenery container in the Dungeon. There is a brick in the wall. [Etc.]

Ok this seems to work so far:

The wall is a scenery container in Start. There is a brown brick in the wall. Instead of taking the brick when the player does not have the scalpel, say "You have no way to pry it free."

How do I make the player though only take the brick if he uses the scalpel with it? I want the player to actually write “use scalpel with brick” or “remove brick with scalpel”.

You’ll need to create an entirely new action. Creating a new action is detailed in chapter 12.7 of Writing with Inform. Your results will look something like this:

[code]A thing can be stuck or unstuck. A thing is usually unstuck.

Prying is an action applying to two things.

Understand “pry [something] with [something]” as prying.
Understand “remove [something] with [something]” as prying.
Understand “use [something] with [something]” as prying.

Check prying:
if the second noun is not the scalpel:
say “You’ll need to use something more appropriate to pry [the noun] free.” instead.

Carry out prying:
now the player has the noun;
now the noun is unstuck.

Report prying:
say “You pry [the noun] free with [the scalpel].”

Before prying:
if the noun is not the brick or the noun is unstuck:
say “[The noun] is not stuck and does not need to be pried free.” instead.
[/code]

However, it’s important to recognize that this will be a lot trickier from a design perspective than just allowing the player to take the brick if they have the scalpel. Once you open up the “use” can of worms, it’s hard to close again, and “use” can’t simply be a synonym for pry - there are so many things you can use, such as “use food with dog” or “use lockpick on lock”, which will need special attention. And as Jim Aikin pointed out, “remove brick from wall” or “take brick from wall” are completely reasonable things to try - even in this context, “remove brick from wall with scalpel.” To avoid frustrating players, that will need special attention too.

Sorry, this is totally tangential and feel free to ignore me, but if I were a player trying to get a brick out of a wall, I would never guess to use a scalpel – I’d be pretty sure it would break. (Or, I might eventually guess but it would be an immersion-breaker.)

I would use the power of rock.

Well in this case it’s not that important since it’s just the start rooms you have to get out of with the one item in it. I was wondering though how you do something like that in general because otherwise how do you create interesting puzzles? If I just make everything work if the player has the appropriate object it’s kinda uninteresting. Then the whole thing just evolves into a collect everything game. That’s why I was wondering how I can make the player use something specific on another object to make something happen or get something out of it.

Well, one thing you absolutely want to avoid is “guess the verb” or “guess the syntax.” That is, a situation where the player knows what they’re supposed to do with what objects but doesn’t know how to communicate it to the game.

For instance, I was recently playing an old (1996) game where at one point there’s a thing that’s too hot for you to pick up and there’s a pair of tongs. I knew that I had to use the tongs to get the thing, but I couldn’t figure out how; “get thing with tongs” didn’t work, “hold thing with tongs” didn’t work,* “get thing” while holding the tongs didn’t work, “use tongs on thing” didn’t work… eventually “pick up thing with tongs” did work, but by this time I was well and truly frustrated.

Now in your case you might not want “get brick” to work when the player holds the scalpel – unlike a pair of tongs, it’s not obvious that if you have a scalpel you might use it to get something. (Leaving aside tove’s excellent point, which is that a scalpel probably really isn’t a good prying tool.) But then you want to have lots and lots of synonyms understood – “get brick with scalpel,” “take brick with scalpel,” as Carolyn said “pry” is a good one – whatever your players will naturally try. (And the way to find out what they’ll naturally try is to do lots of beta testing. Have people who don’t know the solution play your game and see what they type.) It’s also good to give hints if the player tries something that you think is incomplete – if they try “pry brick” you want to tell them that they need to find the right thing to pry the brick with.

And if this is the start room, then what commands you accept is REEAALLLLY important. If your first puzzle can be solved by “use scalpel on brick,” then players are going to expect “use X on Y” to work for the rest of the game. You have to think about what expectations you’re setting up and how you can fairly cue the player as to what kind of commands they can expect to work. Avoiding guess the verb/guess the syntax can be hard, but it’s important for making interesting puzzles.

*This was especially annoying because the hints said “You have to hold the thing with the tongs.” If you have hints, always make sure that it’ll work if the player types something that’s like what you say in the hints.

Yeah sure. I like the general use command. I don’t want anyone to overthink things but I would have added a couple of other options. So is there no way to create a general use command that can work for future puzzles as well? So that I could just say something like “XY is activated by using XY with it.” or “XY is picke dup if XY is used with it.”

I suppose you could make a various-to-various “activation” relation and tie that into a new “using” action, but you’d still need to write rules for what happens when each thing is activated.

I am personally not a fan of “use” as a verb, because a lot of the freedom in IF compared to a graphical game is that you can try all sorts of actions to solve the puzzles. Guess-the-verb isn’t good, but use-is-the-only-verb can cause the same problem: let’s say I’m playing Trinity (the famous Infocom game) and need to cross the grass in Kensington Gardens.

Here is a condensed version of the verbs I would normally apply.

PUSH PRAM EAST. STAND IN PRAM. OPEN UMBRELLA.

If I typed “use pram” in a game which accepted use, I would expect to push it (because that is what one generally does with prams). So how would I indicate the second action? If I hadn’t needed anything except “use” so far in the game, this would definitely be a guess-the-verb puzzle.

I think what makes your example extra tricky is that it involves three objects the player could reasonably reference - the brick, the wall, and the scalpel. I think I’d try something related, but not exactly the same, looking for a way to limit the player’s actions while cueing the correct course of action simultaneously.

Sample transcript:

[code]>x wall
One of the bricks looks like it might be loose.

get brick
You pull at the brick with your fingertips, but some of the mortar is still holding it in place. You can’t move the brick unless you break the mortar first.

break mortar
What do you want to break the mortar with?

scalpel
You wedge the scalpel into the mortar and pull. The mortar breaks and you can now slide the brick free.

get brick
Since you’ve broken the last of the mortar, you can pull the brick free from the wall. You do so.
[/code]

Apart from this exact example… lock-and-key puzzles (where you have an object, and you use the object on something else, and that allows you to move forward) are classic, but I’d encourage you to look for opportunities to make other kinds of puzzles. You might check out the past XYZZY award winners (Best Individual Puzzle: ifwiki.org/index.php/XYZZY_Award … Puzzles%29) for inspiration.

Example 279 (“Alpaca Farm”) from the Inform manuals might be helpful here.

I like Carolyn’s sample transcript; it shows how to guide the player into giving the right commands and so it averts the danger of training him to view >USE X as the solve-everything-action.

I think there’s a reasonable middle ground to be had. Some objects and devices have an obvious primary use, and not accepting “use” in those circumstances can turn into a game of guess-the-verb all by itself.

Good point. Let me rephrase: in general I’m fine with “use [something]” as long as other verbs are also required. What I really don’t like is “use [something] with [something]”, unless it’s really obvious (like a key with a locked door).

Sidenote: it’s interesting that we feel the need to incorporate “use” into modern IF, considering that it mostly came about because the graphical adventures needed a do-all verb.