Suppose we’re writing a game with a heavy focus on characters: their appearance, their wardrobe, and their possessions. We want to encourage the player to interact with these things via the parser, so for each character, we create their possessions, clothes, and body parts as objects and give them all fitting descriptions. Naturally, this also includes the player character themselves.
Now let’s say we get the player in a room with a character named Gregothan who’s very similar to the player in several respects:
- He and the player are both holding a pen;
- He and the player are both wearing a shirt; and
- He and the player both have a pair of eyes.
Here’s the code for this example:
Code
The player carries your pen. The description of your pen is "It's your pen." The player wears your shirt. The description of your shirt is "It's your shirt." Your eyes are part of the player. The description of your eyes is "You can hardly get a good look at them."
Gregothan is a man. Gregothan carries Gregothan's pen. The description of Gregothan's pen is "It's Greg's pen." Gregothan wears Gregothan's shirt. The description of Gregothan's shirt is "It's Greg's shirt." Gregothan's eyes are part of Gregothan. The description of Gregothan's eyes is "It's Greg's eyes."
The office is a room. Gregothan is here.
Test me with "x pen / x Gregothan's pen / x his pen / x shirt / x Gregothan's shirt / x his shirt / x eyes / x Gregothan's eyes / x his eyes".
Now if the player tries to examine Greg’s pen without providing sufficient detail, the parser will (reasonably!) assume the player means their own pen:
> x pen
(your pen)
It's your pen.
To fix this, the player can name Greg specifically in their command:
> x gregothan's pen
It's Greg's pen.
Or, more likely, they’ll just use a possessive pronoun, as it’s faster to type and sounds a bit more natural:
> x his pen
It's Greg's pen.
Naturally, the same set of responses all hold true for examining Greg’s shirt:
> x shirt
(your shirt)
It's your shirt.
> x gregothan's shirt
It's Greg's shirt.
> x his shirt
It's Greg's shirt.
All is well and good until the player tries to look Greg in the eyes, at which point a baffling incongruity occurs in the parser’s responses:
> x eyes
Which do you mean, your eyes or Gregothan's eyes?
> x gregothan's eyes
It's Greg's eyes.
> x his eyes
You can't see any such thing.
For an unfamiliar player, this is kind of shocking! The default prompt for clarification on x eyes is fairly benign – that can easily be cleared up with a Does the player mean: rule by the programmer. But the parser’s complete failure to recognize “his eyes” as referring to a part of Gregothan is as confusing for the player as it is for me!
From the player’s point of view, there is no good reason why you should be able to type “his shirt” to mean Greg’s shirt, but not be able to type “his eyes” to mean Greg’s eyes. In English and, indeed, in most languages, no grammatical distinction is made between something which belongs to something else and something which is a part of something else. If the parser simply rejected possessive pronouns altogether, then it would at least be consistent in a way the player could learn to type around; it’s the disjoint that bothers me!
On a technical level, I assume the disjoint comes from the fact that the “part of” (incorporation) relation is separate from the carrying relation. Presumably, when the parser encounters a possessive pronoun, it searches the pockets of the person the pronoun refers to for a matching item, but it doesn’t search the list of things which are part of said person.
This can be patched over by explicitly specifying
Understand "his eyes" as Gregothan's eyes.
but this quickly becomes tiresome to type out when we have many characters with many body parts created in assembly, especially because we may already want to have several “understand as” statements for each kind of body part (e.g. Understand 'peepers' as some eyes, etc). For a game of sufficient length and nuance, you would need to have an entire document of “understand” statements just to account for everything.
It would be preferable to just patch the parser’s behavior to include parts of things when resolving possessive pronouns, but I haven’t been able to figure out where in the standard rules this behavior crops up – it might be written in Inform 6, which I’m pretty inexperienced with.
So, there’s my problem! Is there an obvious solution I’m missing? Is this indeed something that can easily be tweaked in the standard rules? Or is the issue something much deeper, and I’d be better off simply discouraging the player from using pronouns at all?