Code to show the descriptions for all the rooms and things

Authoring Inform 7
1

I don’t know if there’s already something like this in the documentation, but I’m sharing anyway in case it’s useful. You just type “descriptions,” and it shows you the descriptions for every room and thing. (It shows the current descriptions–not every permutation of every description.)

Section - Not for Release

Describing is an action out of world.

Understand "descriptions" as describing.

Report describing:
	Repeat with current room running through rooms:
		say "[bold type][Current Room][roman type][line break]";
		say "[Description of current room][paragraph break]";
		repeat with current item running through things which are enclosed by the current room:
			say "[italic type][Current item][roman type][line break]";
			say "[Description of current item][paragraph break]";
	If a thing is not enclosed by a room:
		say "[bold type]Things that are not enclosed by a room:[roman type][paragraph break]";
		repeat with current item running through things which are not enclosed by a room:
			say "[italic type][Current item][roman type][line break]";
			say "[Description of current item][paragraph break]".
			
Test me with "descriptions".
8 Likes
2

This is a similar concept to Property Checking by Emily Short.

4 Likes
3

I fully endorse ways to share diagnostic code! The stuff I’ve written has helped me a lot, and it’s taken heat off my testers, who have enough to deal with! It’s important enough, I generally try to put it in my own “tests” header file, so it doesn’t clutter the main file. I find it’s great for when I get sick of testing the game. Then I get sick of it, and I get back to testing the game. Well, that’s how it works in theory.

Certainly listing everything out like this will quickly spot if I swap descriptions and initial appearances, which always seems to happen once.

And Zed jogged my memory–a lot of what I write is probably a riff on Emily Short’s Property Checking as well. I hope going into detail about what I learned from it isn’t going to take the focus away from bg’s script–it’s just I got a ton of mileage from it.

The TLDR is, the below took longer than it should have for me to figure out, and some people may not want to futz with rules, but I wanted to share something PC helped me learn.

Property Checking observations

Looking at Emily’s original code, I realize I could/should have used “the things must have descriptions rule is not listed in any rulebook” instead of modifying her extension Then I’d write a new rule (or “the andrew’s description rule is listed instead of the things must have descriptions rule in the property-check rules.”)

I think the rule I wanted just added one line (e.g. I had an attribute called “negligible” for abstract items so I repeated through not negligible things. This is useful in the case of Daniel Stelzer’s Boolean Variables extension, which is not just about true and false, but about handling options. You wouldn’t want descriptions for abstract options. You could just add the line “if the-thing is an option, next;”)

I also wanted to sort things and people separately, so that necessitated another tweak to the rule. But these are coding exercises.

Emily only wrote the module as something to give people ideas where to start, not as something super-rigorous so I’d offer this refinement to her suggestion in the documentation

	A property-check rule for a person (called the target) (this is the non-scenery must have initial appearances rule): 
		if the target is not scenery and the initial appearance of the target is empty: 
			say "[target] has no initial appearance.".

This may be veering off-topic but I wanted to show another use: for checking that things don’t have the default hints with a hint-by-item framework. (You could do this for rooms, too.) I haven’t fully checked the code for compiling but hope it makes sense.

a thing has a rule called a hint-rule. hint-rule of a thing is usually the empty hint rule

this is the empty hint rule: say "This needs to be replaced before release." instead;

this is the unimportant to story rule: say "This isn't important to the story. It's just there for flavor." instead;

Without Property Checking, a rule could say this:

let unhinted be 0;
repeat with X running through things:
    if hint-rule of X is the empty hint rule:
        say "[unhinted]: give [x] a real hint-rule.";
        increment unhinted;
if unhinted is 0:
    say "Everything has hints!";

Or we could use Emily Short’s framework more directly to say

unhinted is a number that varies.

a property-check rule for a thing (called th):
    if hint-rule of TH is the empty hint rule:
        say "[unhinted]: give [x] a real hint-rule.";
        increment unhinted;

This ensures (if I am vigilant) that if I keep checking, no items will wind up un-hintable.

Anyway, I used her extension a lot, and got a ton of mileage out of it, and I probably reinvented the wheel more than I needed to, to understand rules.

Yet at the same time we don’t have to hold it up as something we have to use – it’s useful just to write something that brute forces through stuff we need to verify works, or where we can see states mid-game, and SHOWME everything just isn’t practical.

So commands like bg’s DESCRIBE have worked really well for me.

Because I didn’t want this to be “Yeah, Emily Short did it earlier!” I have a lot of diagnostics, but they didn’t make sense to share here, and it’s useful just to write them out, because they save a ton of testing time later.

1 Like