Inform best practices mud wrestling: ‘undescribed’

I apologize for absconding with the thread. I know this has been discussed many, many times since I7 was released (and even back in the I6 days, when it was concealed).

But it is an extremely bad piece of world model design, and questions like this are why. I’m not proposing removing it from the library – although, believe me, I am tempted to regularly. But having it as part of the common discourse (as opposed to “a terrible hack that people sometimes have to resort to”) makes Inform harder to learn and harder to use.

1 Like

And Matt, once you get a little more familiar with Inform, I recommend the “Easy Doors” extension by Hanon Ondricek. Extensions help solve a lot of these little problems, but took me some time to wrap my head around adding them to Inform.


If you want to do things Dialog-style, where nothing is ever given a default description until it’s been handled:

Definition: a thing is pristine if it is not handled.
Rule for writing a paragraph about a pristine thing (called the item): now the item is mentioned.

Now you’re in charge of describing everything in its initial state, and the library will only take over once something’s been moved, without the problems of undescribed.

You might want to refine this rule a bit to not override the initial appearance property:

Definition: a thing is pristine if it is not handled and its initial appearance is empty.

Or make it a “Last rule for writing a paragraph about a pristine thing”, if you have other paragraph-writing rules that you want to override this one.


I use it all the time, too. Why is it so bad? It’s never caused a problem that I know of, and it’s super handy when I don’t want something to be scenery but I want it to be, well, undescribed.

And I’m batting 1000 in doing things that the code wizards hate. I use this all the time, too. I have huge “after reading a command” sections in my WIP right now, although 90% of it is choosing numbers from a menu and I do believe you gave that your stamp of approval. The other 10% is saying one-time magic words.

No idea about why a door behaves that way because I don’t use Inform doors anymore-- precisely because they do weird things. How about just saying:

Instead of going west from X room:
    move player to Y room (or now the player is in Y room).

It caused a problem in this very thread!

1 Like

I meant in my own work. I can see why it’s tricky to use if you’re not careful with it.

If we’re talking about a door, I expect it to be (1)present and operable, or (2) be scenery.

undescribed or concealed means that there’s a hidden door somewhere and will need to be revealed before manipulation.

Like Zarf said, to expect a door to be concealed and manipulable is considered broken world model, and as you discovered, you have to code your own door routines.

1 Like

Oh yes. I have been bitten by doors doing weird things so many times. It’s far easier to code your own doors and then you can control everything about them easily.

1 Like

We need a thread for “Inform best practices mud wrestling.”

1 Like

Mud wrestling sounds like a good start for a really bad game for Manon’s bad IF jam. Think of all the funny things that could go wrong.

1 Like

I think people confuse wanting to hide something from the player for plot or prose reasons as a use for undescribed which means the parser will not let the player interact with it at all - as happened in the OPs case, he wanted the door hidden but still available for the player to traverse.

It does work to hide something, but I think it’s intended for a meta-object, like a mechanic for poison gas and you have an invisible object in rooms to check for it called “poison-checkr” you want to make sure it doesn’t come up in disambiguation “Do you mean the poison gas, the poison pen, or poison-checkr?” - IE you never want it described by the parser, and it’s off-limits to the player completely.


The bad thing is that the effects of undescribed are much worse documented than concealed and scenery. In several ways they’re alike, and in several they’re different. My favored approach is to make undescribed better understood.


I have a problem with EVERYTHING, though. Me having a problem understanding something is not an indicator that it is bad. Although I am not arguing with the smart people. I believe you.


I didn’t eve know ‘undescribed’ existed until a few months ago, so I’m not going to weigh in on if it’s good or bad.

But I wanted to see if this is considered generally acceptable. If there’s something I don’t want to show up, I write:

Rule for writing a paragraph about a lured zoo-animal:
	do nothing;

(as an example from a recent game).
Is there any weird behavior or unintended consequences this could cause?

1 Like

One has to keep in mind that mention of the thing will only be suppressed when it would have gotten its own paragraph; behavior will be normal if it’s in or on something. I can’t think of any problems it’d cause, though.


I just submitted a PR (i.e., a code patch that could potentially be included in Inform) that would prevent undescribed things (other than the player) from beiing in scope. We’ll see whether it’s deemed a good idea…

Yeah, I think the way you’re using it is fine. There’s a reason it exists, and it does have plenty of legitimate uses!

My problem with it is that it’s a tool that can solve almost every problem, but usually in a very fragile, delicate way that will crash and burn if the player pokes it wrong. Sometimes this fragile, delicate way is the only way to solve the problem (e.g. WAVE R-REMOVER in Counterfeit Monkey can’t be implemented any other way with the tools Inform provides), which is why it hasn’t been abolished completely. But people see this powerful, general-purpose tool that can solve every problem and, well…try to solve every problem with it. Which leads to fragile, about-to-crash-and-burn solutions to things that could be implemented much more robustly in other ways.

Overall, Inform tries to make it so that the obvious way to do something is also the robust way that won’t break if you lean on it too hard, and “after reading a command” is a massive exception to that.


I’m confused here. That doesn’t prevent you-can-also-see text from being printed. What am I missing about what you’re saying?

1 Like

Hmm, you’re right. This works (edit: I think this might be bad though):

Rule for writing a paragraph about the dog:
	say "";

Maybe the code in my game is doing nothing! That’s the only one that’s blank, all the others say stuff like:

Rule for writing a paragraph about the glass-shelving:
	say "Some art is stored in this room: some glass shelving, [if the glass-shelving is smashed]now smashed[otherwise]in good condition[end if]; a [gingerbread-castle], [if the gingerbread-castle is pristine]attached to the wall[otherwise]pulled off and fallen on the floor in pieces[end if]; and [a soup-painting], [if the soup-painting is pristine]in pretty good condition[otherwise]now with a hole in it[end if]."

You may have helped me find a bug in my code! Unless I was doing it for some other reason…


I also have stuff like this:

Before writing a paragraph about engineering-tear:
	if sorting-quip is not once-delivered:
		now engineering-tear is mentioned;

maybe more useful?

1 Like

Yeah, as a before rule, that’s great.