Referring to a kind by its printed name?

Hello! I’ve been searching around and can’t find any solution, so I’m inclined to believe there isn’t any. But here goes anyway:

I want to give items and people names such as “npc_1”, “chest_1” etc, and give them printed names based on their properties (handled by tables). Now, all that works fine and dandy. They get their properties and their printed names as they should, but the player can’t interact with them using their properties and printed names. And since there’ll be several of each, I can’t assign an “Understand property as” rule to a specific person/thing.

The printed name for all people looks something like “[age], [defining feature] [gender]”, e.g. “old, bearded man”. In short, I want the player to examine the ambiguously named “npc_6”, printed as “old, bearded man”, by typing “x old bearded man” “x bearded man”, “x old man” or “x man” (and if there are more men around, then calling “which do you mean”).

Can this be done easily? It’s a project for fun and learning, so I’m not asking anyone to put effort into writing lengthy codes :slight_smile:

You don’t have to understand it as a specific, named item. You can make it apply to a kind as well. As per §17.15:

A flowerpot is a kind of thing. A flowerpot can be unbroken or broken. Understand the broken property as describing a flowerpot.
The printed name for all people looks something like "[age], [defining feature] [gender]",

Also, in a case like this, you might find it easier to use rules for printing the name of rather than the printed name property. That may be kind of opaque, so let me explain…

An object has a property called the printed name. This is a text property whose default value is the source code name of the object, but you can set it directly:

npc_1 is a person in the hallway. The printed name of npc_1 is "Frevelyn".

and change it dynamically in the course of play:

Carry out giving the Cursed Pot of Name Change to npc_1: now the printed name of npc_1 is "Harge".

There’s also a “printing the name of something” activity, documented in Writing with Inform §18.10. This is what gets invoked when you say [npc_1] or something like that. Its default behavior is just to print the printed name of the object, but you can modify it with “before printing the name of” rules and “after printing the name of” rules. So you could write:

Before printing the name of a person (called individual): say "[age of the individual], [defining feature of the individual] [gender of the individual] ".

(though you probably wouldn’t want that exactly, because your genders are nouns rather than adjectives).

You could even write a For printing the name rule that overrides the normal behavior:

For printing the name of a person when the player is not wearing the glasses: say "blurry individual".

(though this doesn’t override any before/after printing the name rules you may have written).

The punchline is that the understanding by properties thing that Eleas pointed out applies to text properties like the printed name, too:

Understand the printed name property as describing a person.

However, if you use this, the player will need to type the whole name. If the printed name of npc_3 is “Rindy Auld”, then this line will allow the game to understand “x rindy auld” but not “x rindy” or “x auld.” Whereas if she’s called Rindy Auld in the source code, both “Rindy” and “Auld” will automatically be understood.

Anyway! If what you’ve got is working for you right now, there’s no particular need to change it, but I thought you might be interested in those details. And if you want one word of arbitrary text that can be understood (like a proper name), then one approach would be to make that the printed name and use Before printing the name of and After printing the name of rules to get the rest of the properties in. (Though you can also have other text properties that can be understood–you could give an npc a first name and last name property, and have both of those be understood as describing a person.)

An NPC is a kind of person. 

Age is a kind of value. The ages are young, adult, middle-aged, and elderly. Every NPC has an age. 

An NPC has some text called the defining feature.

Table of Defining Features
Feature
"bearded"
"bald-headed"
"skinny"
"chubby"
"well-dressed"
"slovenly"

Understand "man" as male.
Understand "woman" as female.
Understand the male property as describing an NPC.
Understand the age property as describing an NPC.
Understand the defining feature property as describing an NPC.

Test Chamber is a room. 

npc_1 is an NPC in the Test Chamber. 
npc_2 is an NPC in the Test Chamber.
npc_3 is an NPC in the Test Chamber.
npc_4 is an NPC in the Test Chamber. 
npc_5 is an NPC in the Test Chamber.
npc_6 is an NPC in the Test Chamber.

When play begins:
	repeat with X running through NPCs in the Test Chamber:
		if a random chance of 1 in 2 succeeds, now X is male;
		otherwise now X is female;
		now X is a random age;
		choose a random row in the Table of Defining Features;
		now the defining feature of X is "[feature entry]";
		now X is improper-named.
			
Rule for printing the name of an NPC: say "[age of item described], [defining feature of item described] [if the item described is female]wo[end if]man".

Thanks a lot everyone! :smiley:

Mikegentry’s code is exactly what I’ve been trying to do. I tweaked my code with that as reference and now it works!

And thanks for the information Matt, it’s definitely useful knowledge!

There’s another problem now, and that is when two or more NPCs are assigned the exact same properties and the player can’t define which one to interact with. But I guess that’s more a game design issue and not a coding issue. I’m gonna have to think about that :stuck_out_tongue:

Also, my plan is to give NPCs a proper-name property as well, and when you’ve learned the name of an NPC (by talking to it or something) the printed name changes to that instead. That seems fairly easy now with all the information I’ve got. Thanks again!

That’ll combine nicely with Mike’s approach. In fact, since Mike doesn’t even use the printed name property but just uses a Rule for printing the name of, we can assign the printed name at the beginning, and turn off the Rule for printing the name of once we’ve found out the NPC’s name. So:

[code]An NPC is a kind of person.

Age is a kind of value. The ages are young, adult, middle-aged, and elderly. Every NPC has an age.

An NPC has some text called the defining feature.

Table of Defining Features
Feature
“bearded”
“bald-headed”
“skinny”
“chubby”
“well-dressed”
“slovenly”

Table of More-Or-Less Gender-Neutral Names
name
“Casey”
“Jordan”
“Taylor”
“Sam”
“Kris”
“Avery”

Understand “man” as male.
Understand “woman” as female.
Understand the male property as describing an NPC.
Understand the age property as describing an NPC.
Understand the defining feature property as describing an NPC.

Test Chamber is a room.

npc_1 is an NPC in the Test Chamber.
npc_2 is an NPC in the Test Chamber.
npc_3 is an NPC in the Test Chamber.
npc_4 is an NPC in the Test Chamber.
npc_5 is an NPC in the Test Chamber.
npc_6 is an NPC in the Test Chamber.

When play begins:
repeat with X running through NPCs in the Test Chamber:
if a random chance of 1 in 2 succeeds, now X is male;
otherwise now X is female;
now X is a random age;
choose a random row in the Table of Defining Features;
now the defining feature of X is “[feature entry]”;
now X is improper-named;
choose a random row in the Table of More-Or-Less Gender-Neutral Names;
now the printed name of X is the substituted form of “[name entry]”;
blank out the whole row. [so we don’t repeat names]

An NPC can be known or unknown.

Rule for printing the name of an unknown NPC: say “[age of item described], [defining feature of item described] [if the item described is female]wo[end if]man”.

Instead of answering an NPC (called interlocutor) that “hello”:
say “[The interlocutor] says ‘Hi, my name is [printed name of the interlocutor].’”;
now the interlocutor is proper-named;
now the interlocutor is known.

Understand the printed name property as describing an NPC when the item described is known.[/code]

Sample output (it was a lucky guess that the NPC I examined turned out to be Jordan):

Note that all the old ways of referring to the NPC still hold, but “Jordan” doesn’t work until we find her name out, because the understand-by-proper-name line includes “when the item described is known.” Also, we had to change the NPC to proper-named so it doesn’t print “the Jordan” (I forgot this the first time).

Yeah, Mike’s entry (and subsequently Matt’s) was what I was driving at, here. I7 has gotten a lot better at parsing items conditionally. I hope things will continue in that direction in further releases.

Make sure there are at least as many unique defining features as there are NPCs; then, after you assign a feature, add this line:

When play begins:
	repeat with X running through NPCs in the Test Chamber:
		if a random chance of 1 in 2 succeeds, now X is male;
		otherwise now X is female;
		now X is a random age;
		choose a random row in the Table of Defining Features;
		now the defining feature of X is "[feature entry]";
		blank out the whole row; [<-- here's the new line]
		now X is improper-named.

That removes the row from the table and prevents it from being selected twice. Voila, every NPC is guaranteed to be unique.

This is perfect! Works like a charm! Thanks a lot again, all three of you! :smiley: