Improve your room descriptions in seconds with this one easy step!

By default, the way Inform arranges objects in a room description is seldom obvious. It involves the order things are defined in the source code, the order in which they’ve been moved during play, and the intricacies of the implementation of the going action. And lately I’ve been finding this less than ideal.

So here’s a solution!

To decide what number is the calculated priority for (the item - a thing):
	if the item is fixed in place or the item is scenery or the item is a door, decide on 1;
	if the item is a person, decide on 2;
	if the item is pushable between rooms, decide on 3;
	decide on 4.

Rule for choosing notable locale objects (this is the better notable locale objects rule):
	let the domain be the parameter-object;
	let the held item be the first thing held by the domain;
	while the held item is a thing:
		set the locale priority of the held item to the calculated priority for the held item;
		now the held item is the next thing held after the held item;
	continue the activity.

The standard notable locale objects rule does nothing.

Now, room descriptions will:

  • First mention things that are fixed in place
  • Then mention people
  • Then mention things that are pushable between rooms
  • Then mention things that are portable

Want to change this order? Just edit the calculated priority phrase! Lower numbers come first. (This one’s for a game with several pushable things, which is why they get their own section; most games probably won’t need that.)

20 Likes

Now what you are doing here sounds VERY familiar. I ran into the exact same problem: things moving around and I wanted to have some control over the order of things… it got a bit out of hand, though…

Rule for choosing notable locale objects:
	repeat with item running through things in the location:
		if the item is portable:
			if the item is a monster:
				set the locale priority of the item to 10;
			else if the item is an animal:
				set the locale priority of the item to 8;
			else if the item is a man or the item is a woman:
				set the locale priority of the item to 9;
			else:
				set the locale priority of the item to 6;
		else if the item is not a door:
			set the locale priority of the item to 5;
		else if the item is open:
			set the locale priority of the item to 7;
		else:
			set the locale priority of the item to 0;
3 Likes

If I wanted to implement this system but for nondescript items, would I have to make an altered version of the ‘this is the you-can-also-see rule’? It looks like all the relevant code is bundled in there, instead of in some separate activity rules as it is in the case of notable locale objects.

I ask because you are infinitely better at systemic programming than I am. I can do this, I just want to make sure I’m doing it in a not-unnecessary fashion!

EDIT - I know there are extensions, like Complex Listing, but that one doesn’t work with Unified Glulx Input that I’m using.

EDIT EDIT - Actually Complex Listing works with UGI. I was thinking of ‘Advanced List Control’ or whatever it’s called. Looking at the Standard Rules, I think I can get what I want by using a “Before listing nondescript items of…” rule with a prioritising system.

-Wade

2 Likes

Unfortunately, the you-can-also-see rule completely ignores the priority system, and just delegates to the standard “listing contents of” mechanism. If you want to control the priority of those, you’ll need to replace that whole mechanism, or find a way to control the order that the objects appear in the internal object tree.

Off the top of my head I’d recommend the latter. The you-can-also-see rule flags all appropriate objects as “marked for listing”, then calls the “listing nondescript items” activity with “the domain” (the holder of those objects). At this point your rules could intervene with “before listing nondescript items”: remove all those marked-for-listing things from play, then insert them back into the domain in your intended order.

3 Likes

Thanks. Heh, yeah, I’d sort of got to this place myself and been mucking around with it.

My pre-existing system isn’t too bad – it’s just rules that reinsert objects in the location when appropriate to keep them listed first, while leaving alone the natural order of other objects that come after (e.g. depending on how they were dropped.)

My main motivation to try a score-based system was to add the nicety of having people listed before portable things, etc., as per your topic. But mixing hard-scored items with other things that I’d prefer appeared before each other in groups - but whose pre-existing order I didn’t want to mess with arbitrarily - is a pain, especially when combined with worrying about domains as well. I’m starting to talk myself into thinking this is a fair bit of work for a low-priority nicety, and that my original system is already doing the most important work pretty well, and non-buggily.

-Wade

1 Like