intfiction.org

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 , 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

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):




You can use the technique of "understanding mistakes,"

in such cases.

_________________
~Björn Paulsen

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):

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.

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.

_________________
~Björn Paulsen

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:

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:


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

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.



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.

_________________
~Björn Paulsen

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

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.

_________________
Man ska inte tro allt man tänker.

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.)

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.)