WelcomeWhat's NewsORLibraryDownloadsLinksWebMaster@OnyxRing.com

This site
pageviews since

Today's date:

Author: Jim Fisher
Title: Advanced NPCs, Part 1: Pronouns on Steroids

Creation Date: 8/9/2004 6:09:52 PM
Last Updated: 8/9/2004 6:09:52 PM

Common Print Rules
Why Are There So Many Pronouns?
A Plethora of Pronouns
A Stronger More Powerful Pronoun Rule
Even More Flexibility...
Verb and (pro)Noun Agreement
As If That Wasn't Enough...
A Little Note on the Code
Advanced NPCs, part 1: Pronouns on Steroids

Common Print Rules

ometimes writing reusable code is a hassle. This is especially true in the case of pronouns. When creating a simple NPC, one may be tempted to hard code gender phrasing into text. Sentences like
The waiter gives you his pen.


The doctor drops her stethoscope.

may very likely find their way into such an object. Although this seems fine at first glance, and indeed IS fine for instances of an object, text written in this way ties the object to its gender. Dropping "HER stethoscope" is fine for a female doctor, but a male doctor should drop "HIS stethoscope." This can restrict an object's reusability and therefore makes it unsuitable for implementation in a class.

The Inform Developer's Manual (fourth edition) gives a limited example of how to deal with this in chapter IV §26 exercise 62 by defining print rules to deal with a couple of different forms of pronouns (nominative and accusative.)

So everyone will be on the same page, lets review one of the examples given in §a6 page 477:

 [PronounNom i; !this code snatched from the DM4  
   if (i hasnt animate || i has neuter) print "it";  
      else { 
         if (i has female) print "she";   
         else print "he";  

This routine, and the others like it, simply checks for the existence of the appropriate gender attributes and prints out the correct pronoun (i.e.: "him," "her," or "it.") The example in the manual is, I think, intended to point us in the right direction without really addressing all possibilities. That's for us to do.

Why Are There So Many Pronouns?

Some readers may not immediately recognize the references to "Nominative" or "Accusative" forms of a noun or pronoun. Many people, way back in grammar school, learned instead to call these "subject of a sentence" and "object of a sentence." Once upon a time, in languages other than English, all nouns had different forms based upon their placement in the sentence. Ancient Greek, for instance, has four (actually five, but only four of significance). These are:

  • Nominative (subject of the sentence)
  • Accusative (object of the sentence)
  • Genitive (noun possessing or qualifying another noun)
  • dative (receiver of the object)

  • These correlate exactly with how nouns are used in a sentence. For example:
    "The king : nominative (subject of sentence)
    put the wife : accusative (object of sentence, what was put)
    of the banker : genitive (qualifier of the wife)
    in the dungeon." : dative (receiver of the object)

    And again:

    "The boy : nominative (subject of sentence)
    kicked the girl"s : genitive (owner of the ball)
    ball : accusative (object of sentence, what was kicked)
    into the creek." : dative (receiver of the object)

    In English, differences between these forms have primarily disappeared. An apostrophe "s" has been adapted to show possession, and most nouns are now written the same regardless of their placement in the sentence. With pronouns, however, they remain in varying degrees. The dative form has all but been eliminated and shows up only when nouns affect themselves, but a second genitive form also occurs when the qualified noun has been previously described and is so obvious as to be left out.

    See how the masculine pronoun takes a different form depending upon its placement:

    HE gave HIM HIS dog, which was HIS, anyway.

    The last occurrence of the masculine pronoun ("his") is the second form of possession. In this example the two forms are the same. This is not the case for the feminine pronoun:

    SHE gave HER HER dog, which was HERS, anyway.

    The second form of possessive pronouns occurs when the object possessed is obvious and therefore not listed. For example:

    She took her chocolate, but gave you YOURS.

    does not specify chocolate in the same dependant clause as the pronoun "YOURS". If it did, then the form of the pronoun would revert to the first possessive form and the sentence would read:

    She took her chocolate, but gave you YOUR chocolate.

    A Plethora of Pronouns

    The following table shows the pronoun for each person, plurality, and gender:

    Person/Plurality/Gender Nom. Accus. Gen. 1 Gen. 2 Dat.
    1P/Sing I me my mine myself
    1P/Plur we us our ours ourselves
    2P/Sing* you you your yours yourself
    2P/Plur* you you your yours yourselves
    3P/Sing/Masc he him his his himself
    3P/Sing/Fem she her her hers herself
    3P/Sing/Neut it it its its itself
    3P/Plur they them their theirs their selves

    * As a side note, notice that in modern English, second person pronouns almost always are treated as plural even if they represent a singular noun. This was not always the case. For a game placed during the reign of King James, it may behoove the developer to implement the missing second-person, singular pronouns that were commonplace in old-English: Thou, Thee, Thy, Thine, and Thyself, respectively.

    Looking at this table, you may be wondering what some of these forms have to do with writing an NPC class. Specifically you may wonder about first, and second person pronouns as well as the plural pronouns. The answer to this is that you simply don't know how your class may be used in the future. For example, the standard library supports the ability to allow the player to become an NPC (the ChangePlayer() library routine). It may be that phrases like "The troll swings the axe" need to become "You swing the ax."

    Additionally, some library extensions (such as the OREnglish.h file) also allow the game to change the "person" the narrative is being told in. The story could be told in first person and the above example would then need to read, "I swing the axe."

    Plurality too is not beyond reason since an NPC can be constructed to represent a swarm of bees ("They fly after the horse as it runs from them") just as it could represent Superman ("He flies after the horse as it runs from him.") A game where the player shares a body with an NPC might require first person plurality. Text would suddenly need to take the form "We swing the ax" and "We fly after the horse as it runs from us."

    When developing reusable code, it's always best to cover all bases.

    Enough with design, now the implementation.

    A Stronger, More Powerful Pronoun Rule

    Using the above chart, we"ll rewrite the PronounNom routine and name it "I" after the first person singular pronoun (remembering the pronoun is a lot easier than remembering the name of the case of the pronoun, and first person singular is the only form that offers five distinct words for each case):

     Default NarativePerson 2; !if not changing the 
       !narrative, then default 
       !to second person   
     [I obj;!Nominative form (she/he/it/they/I/we/you)  
       if(obj==player){  !talking about the player?  
          if(NarativePerson==1) { !first person?
             if(obj has pluralname) print "we"; 
             else print "I";
          else print "you"; !2nd person, ignore plural  
       else { !not the player, so 3rd person
          if(obj has pluralname) print "they";  
          else { ! is singular
             if (obj has neuter || obj hasnt animate)  
                print "it";
             else {
                if (obj has female)  print "she";  
                else print "he";

    In addition to the above print rule named "I", a rule for each of the five cases should be implemented, plus additional capitalized versions. By duplicating the above example and modifying it just a little, we will end up with ten basic pronoun print routines. Specifically, the five lowercase routines: "I", "Me", "My", "Mine", "Myself", plus the five uppercase version: "CI", "CMe", "CMy", "CMine", and "CMyself".

    Using these print rules, it is now possible to write lines of text that literally transform themselves based upon their use. Look at the following example for a moment:

     print (CI)man, " gave ", (My)man," food to ",  
       (Me)woman,". ", (CI)woman," accepted ",  
       (My)man, " food and then thanked ",(Me)man; 

    With two NPCs, one male, one female, this line above would output the following text:

    He gave his food to her. She accepted his food and then thanked him.

    If the player inhabits the object "man" then the text would appear as:

    You gave your food to her. She accepted your food and then thanked you.

    Or if the NarativePerson variable is equal to 1 (first person):

    I gave my food to her. She accepted my food and then thanked me.

    Or the player could be the woman and the man object could represent a group of monks:

    They gave their food to me. I accepted their food and then thanked them.

    The variations are numerous.

    Even More Flexibility...

    The whole purpose in having pronouns is to keep from having to repeatedly refer to the noun by name. For example, a sentence such as:

    The troll reached into the troll's bag and pulled out the troll's axe. The troll swung the troll's axe and chopped down the troll's tree.

    reads better as:

    The troll reached into his bag and pulled out his axe. He swung it and chopped down his tree.

    Once the noun has been mentioned, it is fine to begin referring to it in pronoun form. It is even desirable to do so. Using the pronoun without first naming the noun, however, is confusing. For independent blocks of text, that are displayed solely as we write them, this is never a problem since we can be assured that we reference the troll first by name, then as a pronoun. NPCs, however, have a tendency to do multiple things at different times, and it is not always known what text has already been printed.

    Consider an NPC that moves around, possibly responding to a call, and speaks 50 percent of the time. Creating text that describes the NPC entering the room and another line of text that describes him talking makes it difficult to efficiently use pronouns because one of the events may happen without the other, or they may both happen together. Assuming both occur, we would like to print the following:

    The troll enters the room. "You called? " he asks.

    If we know that these two sentences will always print together, we can code them by referring to the troll with the standard "The" print rule in the first line of text, and our specialized "I" print rule in the second line of text. This doesn't really work well when the NPC talks without first moving, however, since we would get a pronoun without any prior mention of the troll:

    "You called?" he asks.

    This leaves it up to the player to figure out who the pronoun "he" refers to. To complicate things further, if the troll is mentioned prior to his entering the room, we get duplicated references to the noun. Although this is okay:

    You blow the whistle to summon the troll. The troll enters the room.

    The pronoun is preferable:

    You blow the whistle to summon the troll. He enters the room.

    In addition, when two objects are of the same gender, pronoun use can become confusing:

    The barber grimaced at the sheriff. He handed him a badge.

    Who gave whom a badge? The sentence seems to indicate that the barber gave the sheriff the badge, but was that really what we intended? In cases such as these, it is generally preferable to limit pronoun use to only the first named object of any given gender:

    The barber grimaced at the sheriff. The sheriff handed him a badge.

    Preceding text should also change the pronoun context:

    The sheriff entered. The barber grimaced at him. He gave the barber a badge.

    Addressing both of these points requires another set of print rules that keeps track of the current pronoun-described objects and outputs the name of the object if the use of a pronoun would be unclear:

     Global MPronounObj;
     Global FPronounObj;
     Global NPronounObj;
     [TheI obj checkobj;   
       if(obj hasnt animate || obj has neuter)  
       else {
          if(obj has female) 
       if(obj==checkobj)  print_ret (I)obj;
       print (the)obj;
       if(checkobj==NULL && obj~=player){
          if(obj hasnt animate || obj has neuter) 
          else {
             if(obj has female) FPronounObj=obj; 
             else MPronounObj=obj;

    Of course nine more rules need to be implemented to cover the rest of the print rules developed previously. Additionally, a routine should be created that resets pronoun usage by setting the three pronoun variables to NULL:


    Now the above example can be demonstrated by the following randomized code (assuming the sheriff and barber objects have been defined appropriately):

     if(random(2)==1) print (CTheI) sheriff," entered. "; 
     if(random(2)==1) print (CTheI) barber," grimaced  
       at ",(theMe)sheriff,". "; 
     print (CTheI)sheriff," gave ",(theMe)barber,"  
       a badge.";

    Verb and (pro)Noun agreement...
    The reader may have noticed that many of the examples above have been given in past tense. This is not only to demonstrate diversity, but also for the sake of clarity, since it avoids a quirk in the English language that should be discussed now. Specifically it is the agreement of verbs with their Nominative noun's plurality when described in third person, present tense.

    Yeah, I know, it sounds confusing, but English speakers understand this on an intuitive level so a couple of examples should clear this right up. First lets look at a present tense verb used with a first person noun:

    I run.
    We run.

    Okay, that was both singular and plural forms. No change in the verb. We can see the same thing in second person:

    You run.

    Even third person plural follows this rule:

    They run.

    The third person, singular noun disrupts our continuity, however, because it makes the verb change form:

    He runs.
    She runs.
    It runs.

    For most verbs, this change takes the form of an "s" being appended to the verb. Not all, however:

    We do.
    He does.


    They fly.
    It flies.

    And again,

    I wax.
    It waxes.

    Print rules won't help us here. What we need is a routine that checks the noun and chooses the appropriate verb form, or possibly appends an "s" to the verb for us if appropriate. Luckily, verbs only follow nominative nouns so a single lowercase and a single uppercase routine can be put into place to affect this change. Here's the uppercase version:

     [CIVerb obj verb altverb;
       print (CTheI) obj," ";
       if(obj has pluralname || obj~=player)  
          print verb; 
          print verb,"s"; 
       else print altverb;

    Routines always return a value of some kind. Roger Firth's article, "Print Rules" suggests creating a do-nothing print rule to discard the return value rather than print it:

     [ignore o;]; 

    Having done this, the IVerb routines can be implemented in the print statement like this:

     print (ignore)CIVerb(obj,"drink"),"  
       the glass of milk.";

    And like this:

     print (ignore)CIVerb(obj,"smash",
       "smashes")," the empty glass."; 

    Depending upon the attributes of obj and what text has already been printed, any of the following could be printed:

    The troll drinks the glass of milk. He smashes the empty glass.
    You drink the glass of milk. You smash the empty glass.
    The monks drink the glass of milk. They smash the empty glass.

    As If That Wasn't Enough...

    Additionally, there are a few special cases regarding the so-called "verbs of being" that change based upon plurality and person. The standard library attempts to address these with the IsOrAre print rule. If implementing a game in first person, this routine would have to be replaced to also support "am". Better still, a variable could be implemented that checks the tense a game is being told in and adequately supports "was", "were", and "will".

    A Little Note on the Code

    The samples described above are just that, samples. Although the text often refers to duplicating code and changing portions of it to match, this really isn't the best way. A skeleton function containing the duplicated algorithm which accepts all variations of text as parameters would take up significantly less space, and be easier to maintain. You can see for yourself because...

    The ORLibrary entry
    ORPronoun.h contains a complete implementation of the techniques discussed in this article.

    Knowledge, Conversation, and Learning


    Copyright 2004 - 2021 : Jim Fisher
    OnyxRing.com has been given the potentially non-exclusive right to display the content of this article. However the original author retains all rights. Permission to reproduce this article -- either in part or in whole -- is left strictly to the discretion of the original author.

    Table of ContentsAuthorsSearchIndex
    Would you
    recommend this
    article to
    someone else?
    You bet I would! Heck No!