Describing dark rooms

Hello again! Had i known the kinds of nightmares that dealing with dark rooms in Inform7 would cause, i might not have planned a bunch of puzzles around them.

i want the player to be able to bumble around the game’s rooms in the dark. That means that i need to be able to describe rooms, individually and uniquely, when they are dark.

As usual, i have reached the end of my tether attempting this, and have exhausted online resources.

Not sure what kind of spooky voodoo goes into describing (or describing the description of) rooms, but here’s the current weirdness:

[spoiler][code]Rule for printing the description of a dark room:
say “[printed name]”; [this is a testing measure, and weird stuff happens - see below]
if the room is the Kitchen:
say “[darkKitchen]”;
otherwise if the room is the Den:
say “[darkDen]”;

To say darkKitchen:
say “It’s pitch black in here, but it smells like the kitchen.”;

To say darkDen:
say “You can’t see a thing, but the squish of shag carpet between your toes confirms that you’re in the living room”;[/code][/spoiler]

Seems kludgy, right? Believe me, i tried a lot of more level-headed stuff before i got here. Here’s what happens:

So here’s my big fat question:

i am saying “Rule for printing the description of a dark room,” and the subject of that rule appears not to be the room, but the cardinal direction that brought me into the room. That seems to be why my earlier, saner attempts at this failed, like this one:

[spoiler][code]A room has some text called dark description.

Rule for printing the description of a dark room:
[none of these worked]
say [dark description];
say “[dark description]”;
say [dark description of the room];
say “[dark description of the room]”;
say [room name][dark description];
try describing the room [sometimes i added “instead”];
try looking at the room;
try printing the dark description of the room;
try printing the dark description of the noun;[/code][/spoiler]

In the rare case where one of these lines would survive compilation, i would enter the room and encounter a run-time error, essentially saying that “north” was not allowed to have a property called dark description.

i come from a programming background, so i’m trying to see the Matrix here… and from what i can tell, a reference to the room is not being passed to this rule, but rather, a reference to the direction traveled to get there.

The only documentation examples i’ve seen about working with dark rooms tell me how to either override the description of ALL dark rooms, or how to add a light to a dark room so that the player can see. Neither of these are suitable for what i’m trying to do. What vocab/understanding am i missing to tackle this problem?

Rule for printing the description of a dark room: say "[darkdesc of location]" instead.

I think something like this will work. Or depending on how your spacing works out,

[darkdesc of location][line break]

The issue you’re running into is that the “printing the description of a dark room” activity doesn’t actually take any arguments – hence the runtime error, since Inform doesn’t know which object’s printed name you’re referring to, and substitutes the printed name of the default value for the object kind – north – instead. Likewise “the noun” is the direction you just went in with the going action, as “the noun” is defined only by the command parser.

Here’s what you want to do:

[code]A room has some text called dark description. The dark description of a room is usually “It is pitch dark in here, and you can’t see a thing.”

Rule for printing the description of a dark room (this is the new dark description rule):
say the dark description of the location.[/code]

[On preview, Chin said much of this more succinctly, but in case this helps…)

As far as the matrix goes, there are a couple separate things going on here, depending on which formulation you’re using.

One is the runtime error you get when you write “[darkdescription]”. The darkdescription is a property of an object–but Inform doesn’t know which object you mean, so I think it’s trying to evaluate the darkdescription of nothing, which is giving you a run-time error.

(There are sometimes where something is so closely tied to an object that you can get away with not specifying which object you’re talking about, and Inform will infer it correctly. For instance, after defining color as a kind of value:

A block is a kind of thing. A block has a color. The description of a block is "It's a block."

Inform successfully infers that “” means the color of a block. But in your case, “[darkdescription]” isn’t in a place that’s tightly enough tied to anything for Inform to be able to make that inference.)

In some other places you use “the room”–but “room” is the name of a kind of object, not the name of a specific thing. So Inform doesn’t know which room you mean, and that can lead to various weirdness and unpredictable results. (One hairy one is when you write “if the room is dark”; that gets evaluated as “if a room is dark” and comes out true whenever any room is dark. At least that was true in older versions of Inform; now it might not even compile, I forget.) You know what room you mean, and I know what room you mean, but Inform doesn’t know what room you mean. This is one of those cases where using natural English patterns trips you up and you have to remember that the pseudoEnglish is really a programming language.

Finally, when the game is printing “north,” I’ll bet that’s when you used “the noun.” The noun is the object of the action–and in this case the action that was being performed was the action of going north, so the noun was “north.”

As Caleb and Chin said, if you want to refer to the room that the player is in, use “the location.”

Thanks for your help! Caleb, the understanding that “the noun” refers to the prompt input is eye-opening to me … this whole time, i’ve thought it referred to the subject of the conditional clause.

chinkeeyong - i SWEAR i originally wrote it the way you just showed me, but i think the missing concept was calling the room “the location” instead of “the room” (which, to my mind, is far more intuitive … otherwise, why wouldn’t the syntax be “Rule for printing the description of a dark location” ? Why artbitrarily switch between calling it a room or a location?)

(THE ABOVE WRITTEN BEFORE i HAD SEEN matt w’S EXPLANATION)

Ah - so saying “the location” is a way for Inform7 to overcome the ambiguity of the word “room”? It’s super confusing, and i wish that example was included in §18.22. i don’t think i encountered ANY instances of the word “location” in the docs while i was struggling with this problem.

See section 3.25, “The location of something”.

“The location” is shorthand for “the location of the player.” It is an unambiguous description of a specific room, not the “dark room” in “printing the name of a dark room” as you might believe.

I’m glad for the full explanation too, so thanks everyone – programming for me is sort of like alchemy. I work from examples and often don’t quite understand why things function the way they do.

A kind term (room, thing, person, door) is always ambiguous in Inform. So “a room” makes sense in various contexts, but “the room” is almost certainly a mistake. Same for “a thing” versus “the thing”, and so on.

Right, and that’s why i thought that

Rule for printing the description of a dark room

would automatically make the currently inhabited room the “dark room” in question, since Inform7 is trying to print the description of the place that the player has just arrived at. Given that, i would think that “a dark room” is parameter/placeholder for the current room, and not an ambiguous room.

That’s why i think this is the very first thing i tried:

Rule for printing the description of a dark room
say the dark description of the room.

It makes sense that Inform7 should know what the current room is, because it is trying to print the description of it. That’s why this rule kicks in at all. It is also logical, then, to think that “a dark room” is a variable/parameter placeholder that contains a reference to the current room, because that’s what this rule is all about. And given THAT, i think it’s reasonable to then attempt to say or print the “dark description” property of the given room. The current room should be the focal point - the featured parameter - of this whole structure, should it not? Why should “Rule for printing the description of a dark room” refer to the direction i typed to move myself into the room?

i know it’s useless to kick and scream about the way Inform7 should work, but i begin to feel stupid asking for help, when the answers all look like “give the ball to the dog” (after my attempt to “give the dog the ball” results in a spectacular trace overflow crash)!

In programming terms, you’re trying to rewrite a function called ForPrintingDarkRoomDescription(), then calling a variable of a nonexistent argument of the function. This makes Inform cough up a runtime error, then substitute the default value for an argument of type “object,” which is the direction north.

I do agree that the name of the “printing… dark room” activity should be less misleading.

First: “The noun” and “the second noun” are special values filled in by the parser. They’re meant to be used in action rules; better names might be “direct object” and “indirect object”. If the player typed >EAT THE SANDWICH, then “the sandwich” is the direct object. So as long as it’s processing the action of eating the sandwich, “the noun” should always be the sandwich. Never anything else.

But regarding your actual syntax! Inform actually has a feature for that. Whenever you use an object in a condition, you can give it a special name in the context of that condition.

A fish is a kind of thing. Instead of examining a fish (called the particular fish I care about): say "[The particular fish I care about] is kind of disgusting, and you don't want to get any closer to it."

Here “the particular fish I care about” is an arbitrary name. I could also have used “the item” or “asdfghjkl”. This also works within a rule:

Every turn:
    if the player is carrying a fish (called the fish-which-the-player-has):
        say "You're beginning to dislike carrying [the fish-which-the-player-has]."

HOWEVER…

For historical reasons, printing the name/description of a dark room is an exception to this pattern. Which is really really annoying. (Technically, it’s because the “…dark room” is part of the activity name, rather than a preamble condition.)

Fortunately, it’s the only exception I know of. Unfortunately, you came across it right at the beginning.

Yes, because that’s another thing i remember trying:

And it didn’t work, so i kept trying things like:

say [the dark description of R]. say [R][dark description].

…and so on and so forth until i was climbing the walls.

Inform’s “dark” flag for a room also triggers other behaviors, such as disabling looking and taking.

What you may wish to do is define a new adjective like “A room can be dim.”

Then you can treat a “dim” room as dark for your purposes, and change the rules as you like based on that instead of working around I7’s specific concept of and rules for darkness. You could still use “dark” perhaps to restrict a player while blindfolded.

Then you just define things accordingly:

[code]
“The description of the coat rack is [if the location is dim]There’s a skeletal thing in the corner[otherwise]A coat rack is in the corner[end if].”

rule for printing the name of coat rack when the location is dim:
say “skeletal thing”.

Understand “skeletal” and “skeletal thing” as the coat rack when the location is dim.

Check taking when the location is dim:
if a random chance of 1 in 2 succeeds:
say “You fumble for [the noun] but find you can’t get hold of it.”;
stop the action.[/code]

I recommend against this particular thing, though. It comes across to the player like this:

You have to be very careful about the feedback you give players; it’s very important to give players feedback that points them toward what they need to do (not necessarily leading them by the nose, but giving them something that fairly suggests where they can look); and it’s very very very important not to give them misleading feedback. In this case the feedback they get (on a random chance of 1 and 2) is “You can’t do that,” and when it turns out they can do that, well…

There are ways you could set up a situation where the player realizes that in the future they’ll have to try things over and over… but I’m not sure what it would add to the game. There’s a certain amount of atmosphere, but the extra aggravation it gives the player would outweigh any gain in atmosphere, I think.

That was a design rant and is irrelevant to the coding issue, ofc.

Thought someone out there might know more about it.
I remember 2 years ago there was a drum and bass thing on the whole top floor of the union. Absolutely quality night, but ive never heard anything more about it, anyone know if theyre going to be organised anymore?
Was it done by RaveSoc as well, or just a union event?

I apologize to you and the OP.

I was intending to demonstrate that the author could write whatever code they wanted into their rules. Obviously that was a poorly chosen example because my head wasn’t thinking of “feedback to the player” but “simplified example of what the author could do”. I inferred the author already had in mind behaviors for dark rooms, but didn’t know exactly what they were.

But nonetheless, 1000x apologies for this serious faux pas.

Oh, I hope I didn’t make it come across as though you needed to apologize! From a coding perspective, your example is great as “This is a kind of thing you can do with the dim room kind.”

I did a bunch of random things for darkness in Transparent and learned a whole bunch about what the player needs for feedback, so I should be much more aware!