Newbie: Scenery and Unique Actions

Authoring Inform 7
#1

I am very new to Inform and am finally giving writing IF a go. I’ve been tearing through tons of examples online, but I’m not sure what the recommended methods are for my three basic questions.

When I drill down into detail about a room, should I just constantly create a new item with “Is scenery” for each detail the player may want to look at. Putting aside my OCD attention to detail :slight_smile:, I have a room, which has a table, which when looked at has some odds and ends like “scattered plates”, and the plates are stained from last nights meal. None of this is there for game play purposes or are usable items. I don’t want the table to support objects or plates to be picked up. It’s all just dressing if a player wanted to dig deep into details just for the fun of it.

Should I create each of these as:

A table is here. Table is scenery. “The table…”
A plate is here. Plate is scenere. “The plate…”
A stain is here. Stain is scenere. “The stain …”
With corresponding: understand “plates” as plate.

Will that create issues having so many objects or lines of code? Should I write is as some sort of command: Instead of “x table” say “The table has four legs…”? Or is creating a multitude of scenery objects simply the price to pay for going nuts with details?

Second question, if I write a new action such as “scrub floor”, how does Inform know it applies only to a specific room where scrubbing is important to the story versus a command of scrubbing that I want available no matter where the player goes?

Third question, if I want to help guide a player away from actions that I don’t want, must I define the action first, then create another line of what to say in place of “That’s not a verb I recognise.” Two separate lines? Or is there an easier way to write one line that accomplishes ‘instead of doing an action you dont understand, just say this’?

Thank you,

Tom / Hardwater

#2

Way I see it, there are two schools on this. The first is the most straightforward: model each of these as a scenery object and provide innocuous error messages whenever the player tries to interact beyond superficial examination (i.e “The [x] is unimportant.” or "You try to push [y]). The second school employs shorthand. Here, you group the objects together so that the table, dishes, tablecloth etc actually refer to the same object, thus logically grouping related items together. For an example of this technique in action, check out The Dreamhold by zarf (specifically, the glass-fronted cabinet and its contents).

Which technique is best is a matter of taste. Some players are fine with different objects being represented by a single one, others feel it’s cheap and/or boring. Your mileage may vary.

No. God no. Bearing in mind I’m no I7 maven, I still can’t see how command substitution could possibly end well. Scenery objects are barely significant in terms of size, so you won’t really gain anything by overriding the object tree model in this way.

It depends. Realistically, there’s always going to be a cutoff point somewhere; for me it’s when there are so many similarly named objects in the same room that the parser picks the wrong one. Barring that, you’re free to go wild.

Generally, when you want to restrict actions, you add a check rule or an instead rule to block undesired actions, as below (I used a check rule):

[code]A room can be dirty or clean. A room is usually clean.

Floor-scrubbing is an action applying to nothing.
Understand “scrub floor” as floor-scrubbing.

Check floor-scrubbing when the location is not dirty: say “The floor here doesn’t need scrubbing.” instead.

Carry out floor-scrubbing: now the location is clean.
Report floor-scrubbing: say “You scrub the floor until you can see your own reflection.”

The Parlor is a room. The Porch is west of the parlor. The porch is dirty.[/code]

You can use the technique of “understanding mistakes,”

Understand "act" as a mistake ("To join the actors, you have to adopt a role in the play! Try PLAY HAMLET or similar.").

in such cases.

#3

I’m just barely less new than you are, but the way I understand it, you’d use the above to create a functional but minimally useful action that could apply in any room, and then use a more specific after or instead rule to advance the story (thrown together here; not guaranteed to work):

[code]The metal rod is an item. “Old, rusty, but important.”

After floor-scrubbing when the location is the porch for the first time:
say “As you scrub the boards of the porch, you find an old metal rod wedged into a crack.”;
now the player has the metal rod.[/code]
Also, I have the same problem when creating games. Of course, I also don’t like saying that the player can’t pick something up. Carrying capacity becomes important quickly. I’m not sure if that’s the best way to do it (never gotten anything to the point where I could run it by anyone for testing, which might be part of the answer right there), but from what I understand, items take up a rather tiny portion of the memory, especially if you make them scenery.

#4

Either way is fine. You could also combine the two. I generally use After or Instead rules for one-time events, but it’s a matter of personal taste.

#5

As a rule, when designing you should try and think general.

I would rather implement a verb “scrub” that works for anything and then catch the specific behaviour:

[code]Scrubbing is an action applying to one visible thing. Understand “scrub [something]” as scrubbing. [also, add synonyms here <—]

Check scrubbing:
if the noun is not the [floor]:
say “You should stick to scrubbing floors.”;
stop the action;
else:
say “It’s spring cleaning time!”.[/code]
That saves the parser when the player (as he would surely do!) tries and scrub something that is not the floor. (The [floor] in brackets it’s because I don’t know how you called it. There is no “floor” pre-implemented in Inform).

Now another thing to be said: if the particular action triggers just for one object you should use the Carry out rule. Else, a more specific Instead rule should be used.
Again:

[code]Check scrubbing:
if the noun is not the [floor]:
say “You should stick to scrubbing floors.”;
stop the action.

[----- if you have just one floor or a kind of things named “floor”:]

Carry out scrubbing:
say “You scrub at the floor”;
[another action here, like turning the floor to “clean” etc.].

[----- else if there are several “floors” and several different outcomes:]

Instead of scrubbing the main room floor:
say “You scrub at the main room floor ruining its surface”;
now the main room floor is ruined;
etc. [/code]

I’m not able to test the code atm, but it should give a general sense anyway.

#6

That’s true enough. I decided not to do that purely to sidestep the whole issue of adding a floor object (either backdrop or kind), since I wanted a tidy example.

Check scrubbing: if the noun is not the [floor]: say "You should stick to scrubbing floors."; stop the action; else: say "It's spring cleaning time!".

As an aside – and this may be a personal preference – I’d be wary of using check rules in this way. Unless you have something quite particular in mind, description of a successful action is generally handled by the Report rules.

Check scrubbing when the noun is not a floor: say "You should stick to scrubbing floors." instead. Report scrubbing: say "It's spring cleaning time!"

#7

Yeah, of course. I was just typing fast while thinking to the generic issue. A report rule is better for a hundred reasons.

#8

Also, in this particular case, the Standard Rules already understands “scrub [something]” as rubbing. So, if you implement the floor as a thing, you might as well use the existing rubbing action.

The Bar is a room. A floor is a backdrop. It is everywhere. The Street is north of the Bar. Instead of rubbing the floor in the Bar: say "Foo." Test me with "scrub floor / n / scrub floor".

#9

Really, the carrying capacity of the player should be important seldom or never. Inventory-management puzzles are annoying and add little to a game, and a petty realism is the hobgoblin of little minds.

What is important is that when you allow a player to pick something up, you’re signalling that it’s likely to be useful later on. It’s basically unfair to the player if you let them collect forty objects, only two of which are useful for anything.

Similarly, if you implement a big scenery object with dozens of individual details, that’s likely to attract the player’s attention; if the author put all this work into the table, something on it must be important, right? (How important this is will vary depending on the kind of game: if you want your game to be slow-paced, exploratory and more focused on scenery than puzzles, you can get away with a much higher level of detail.)

#10

I think it would be OK to let the player pick up things like the plate; if it’s there anyway, then you might as well allow the obvious sorts of interaction. For instance, I’d expect to be able to open and close a cabinet or turn on and off a radio, and I’d much rather perform a useless action successfully than get an arbitrary-feeling denial like “You know there’s nothing interesting in the cabinet” or “You don’t feel like listening to music right now.”

(I might be alone in this, but I don’t actually like the IF convention of not implementing something unless it’s important. I like the atmosphere of a detailed, well-implemented scene and don’t like the nitpicky “examine everything because there will be something important on the windowsill” mechanic of games where every single implemented thing is game-essential.)

#11

Thank you all for your assistance. It’s been very helpful.

I’m still running into an issue where I want a drink dispenser that has a button in its description to give the player a cup of coffee when pressed. It seems how Inform 7 wants this to be done is through many more lines of code versus what should just be two or three lines in my mind.

In my perfect world, I want Inform to recognize:

If player types ("press button" or "push button") and the location is the Galley: say "Nice text blurb here."; give player cup of coffee. <--- a predefined item

But through my lack of skill and tireless research, I’ve only been able to come up with this monstrosity that doesn’t quite work yet.

[code]Pressing is an action applying to one visible thing.

Understand “press [something]” as pressing.

Carry out Pressing:
if the noun is button and the location is Galley: <---- and this wont work as the button doesn’t exist and really shouldn’t need to in my opinion
say “Nice text blurb here.”;
give player cup of coffee.

** and additional code, an Instead? that makes “pushing” the button also work.**[/code]

Am I making things too difficult? All I want to do is have a specific phrase in a specific location trigger some text and maybe give an object. It seems like it should be a lot easier than what I’m struggling through.

And Katz, I agree with you. That’s the style of IF that I prefer. Plenty of details where your reward for sniffing about (if you want) is extra details about the world and plot. If the only points of detail are game specific then it’s a little too “on the nose” as they say. Is this considered bad form in IF these days? As it stands now, for every noun that gets into my room description I create a piece of scenery for the player to examine if they choose. Seems fun to me. :slight_smile:

Thanks,

Tom / Hardwater

#12

Well, I don’t see why it would be so much more difficult to create the button object. The pushing action already exists in the standard rules so you don’t even need to make a new one.

[code]The button is part of the drink dispenser.

Instead of pushing the button for the first time:
say “Nice text blurb here.”;
now the player carries the cup of coffee.
[/code]

To me that is just about as clean and compact as your “ideal” version. It’s much better from the player’s point of view anyway: if you define only the “press button” action with no button object and the player types “examine button” (or some other action) they get the “You can’t see any such thing” error which basically says that the button doesn’t exist and there’s no use even trying to push it.

#13

It seems like you keep coming back to phrasings like “if the player types”; in other words, you’re trying to perform the role of the parser yourself. That way lies frustration – there’s a pre-made parser for a reason! Sure, you think you’ve thought of all the phrasings that should trigger the coffee dispenser, and in this case it may really be as simple as just “push button” or “press button,” but combinatorics is not on your side, here: what if it’s a red button? what if the button is just part of the machine? Many players will try to use “push red” or “press dispenser” as shorthand, and they’ll be frustrated when their chosen phrasing hasn’t been accounted for. There are ways for you to access exactly what the player typed, but the actual need for that information is very rare. (One such case might be that you want the player to enter their name, for example.) Teaching the parser a few new words (“button,” in this case) is going to be a lot less work in the long run.

To answer your concern about the button not really needing to be its own separate entity: you can simply set “button” as a synonym for the coffee machine, like this: [code]Understand “button” as the drink dispenser.

Instead of pushing the drink dispenser:
say “Nice text blurb here.”;
now the player carries the cup of coffee.[/code]

#14

What you want to do here is basically string-matching rather than parsed commands. You’re right that I7 doesn’t want you to do it, because it’s a bad idea for a lot of reasons: most obviously, it will be extremely confusing for the player unless they carry out only those actions, using only those precise phrasings, that you’ve bothered to implement. In the example you’ve got, the button only exists when you’re pushing it.

That’s not frowned upon at all; you’re certainly expected to create an object whenever something gets mentioned by your text! The issue is more about how many objects you choose to mention in the first place; IF writers can get very careful about avoiding mention of things that they don’t want to implement.

Rich, detailed implementation is a perfectly good design choice: but like any design choice, it should be appropriate to the kind of game you’re planning to write. If you want a game that’s largely about walking around and taking in your surroundings, like The Cove, The Fire Tower or She’s Got a Thing for a Spring, detailed scenery is the right choice. If you want a fast-moving, action-oriented story, detailed scenery can be a distraction and reward behaviour that you don’t want to encourage. The important thing is to know the kind of game you want to make, and make choices that don’t contradict that aim. If you find exploratory, scenery-oriented games fun, that’s the sort of game you should make.

#15

However, if you adopt that approach and the player tries to push the machine itself (not an impossibility if, for example, he thinks there might be something hidden behind it), he will get a cup of coffee instead of moving the machine.

Robert Rothman

#16

Thank you so much for the help.

[code]The button is part of the drink dispenser.

Instead of pushing the button for the first time:
say “Nice text blurb here.”;
now the player carries the cup of coffee.[/code]

This basic setup was just what I was after and works as I had hoped.

I am sorry to keep pestering you all with endless questions, and even more will come, but I have yet another issue.

I want to change the text describing a character as part of the room contents after he has been seen for the first time. I’ve spent the better part of 45 minutes tearing through multiple documents, but I cannot find how to accomplish this.

Here is code below that does not work as I cannot find the relevant command for a character. “Visited” works for rooms but not with Mr. Anders below.

Anders is here. Anders is a man.  "[if first time in the presence of Anders]Anders, the ship's engineer sits at the table[otherwise]Anders sits at the table[end if].". The description is "He is the Polera's engineer. A muscular man who seems constantly covered in grime every time you see him. Anders is a good man to have aboard, though he does get a bit emotional about 'his ship'."

Is there a simple [bracket] command to do what I want? If so, is there a list of all these possibilities so I don’t have to keep bothering you all? I have found multiple pages in the different documents that describe various things Inform can do such as: in the presence of, If/otherwise/end if, first time, etc. But is there a single glossary of the different accepted items Inform can take inside of brackets?

Thanks again,

Tom / Hardwater

#17

For this case you want just

“[one of]Anders, the ship’s engineer sits at the table[or]Anders sits at the table[stopping].”

This is a first-time/second-time test which applies to the particular printed message that it’s in. You don’t need a test for the presence of Anders, because the whole line is a property which is printed when Anders is in the room.

As for a list of bracketed commands, you can put any phrase in brackets, really. See the “Phrasebook” panel in the IDE’s index tab – it’s grouped into categories so it’s fairly easy to navigate.

#18

And in fact, I7 offers a shorthand for this specific need, since it comes up so often: “Anders[first time], the ship’s engineer,[only] sits at the table.”

Every time that text string is printed after the first time, the text within the brackets will not be displayed.

#19

Perfect. Thanks again for the help.

And now for Question #…what am at, 5 now? How many do I get before the interactive fiction community bans me for life? 4? :slight_smile:

Question 5ish!: I’ve got my character described well and able to be talked to. How can I get him to randomly say a phrase every 3-5 turns lets say.

I see the “every turn” time frame but typing “every 5 turns” is a no go. I’ve been looking at the egg timer example in the documentation, but I’m not certain how to get such a timer started. Create a variable of babble for each character. Every turn the player can see the character increment babble by 1. When it reaches 4 turns, say your line and reset the variable?

Did I just say variable babble? :wink:

Tom / Hardwater

#20

You need a bit of math for the “every X turns” thing.

Every turn when the remainder after dividing the turn count by 5 is 0: say "Ding!"
You could use a variable or scenes, but this is the one-liner solution.