Let's begin with a hypothetical event in which Subject attempts to kiss DirObject. We can readily imagine the possible options of this verb: perhaps the woman will respond passionately, or perhaps she will spurn the kiss, or shy away from it, or slap the man, or just kiss him in a regular fashion. These are all reasonable options. But consider this: what if the woman's boyfriend finds out about the same event? What are his options? They certainly aren't passionate kissing, spurning, etc. They will run along very different lines: punch the guy, leave the gal, shoot them both, etc. The important observation here is that the set of options available to a character depend upon the dramatic role that s/he is playing: object of romantic attentions, jealous lover, overprotective parent, etc. Thus, whenever we create a set of optional reactions to a verb, we must also define the role that can take these reactions.
Now, we all have a vague idea of what a role is, but right now we're working with interactive storytelling technology, and our loosey-goosey concepts of roles need to be tightened up for purposes of computability. In other words, we need a precise definition of a role. My first pencil-sharpening observation is that a role is an all-or-nothing concept: either a character fits a role or he doesn't. We don't imagine somebody who is "kinda-sorta" a jealous lover, or "kinda-sorta" an overprotective parent. Either you fit the role or you don't. Of course, within that role, there are many variations in intensity; a jealous lover can still give his blessing to the new couple and walk away; an overprotective parent can smile sadly and say, "Just make sure that you use a condom." Or they can swing to the opposite extreme. The important point is that our problems are greatly clarified by this act of simplification. First we make a black-and-white decision as to which role the character fits; then we make the more nuanced judgement as to which reaction the character will take.
A black-and-white decision is the kind of thing that programmers love, because it's ridiculousy simple to calculate. What it requires, though, is a means of precisely articulating the conditions that will yield black or white. Fortunately, we have exactly the tool for this kind of thinking: Boolean logic. This is a formal language of expressing simple black-or-white relationships. For example, suppose that we wish to specify the two very different roles cited above: kissee and jealous lover. The specifications might look like this:
The first formula is fairly simple. Its first oddity is its reference to this "CharacterInQuestion". We do this because this formula is a test that must be applied to any possible character. In other words, we can't take the simple route of just fingering the kissee; we have to have a question that could be asked of any character, a question that yields a simple yes or no answer. This rather indirect manner of approaching the problem may seem unnecessarily circuitous, but in fact it allows us great power in specifying complicated situations. Thus, we'll run though the entire cast of characters, asking, "Is this person the Kissee?" and testing the answer with the above formula. When we get a "yes" answer, we know we're there. In this case, a "yes" depends only on the ridiculously simple question of whether the CharacterInQuestion is the direct object of the sentence "Guy AttemptsToKiss Gal".
We do the same thing with the Jealous Lover. Again, the formula is ridiculously simple, with only one added complexity: we must ask who is the Lover of the CharacterInQuestion. (Those square brackets are techie-speak for "of the".)
Now, if this were all there was to it, then you'd be justified in dismissing all this as overblown techie hocus-pocus -- lots of arcane-sounding stuff for thinking simple thoughts. But the value of this hocus-pocus lies in its extensibility into much more complex territory. For example, suppose that we wanted to create a special role for a "jealous dater", that is, a guy who has dated the gal a couple of times, but there has been no formalization of their relationship. Under these circumstances, he might feel entitled to some proprietary rights, but she might equally well feel that he has no such rights, and a conflict is created. Our task is to define the circumstance -- and the role definition is precisely the place to do it. I would use something like this:
This introduces a special function that checks the history of the story so far, asking if CharacterInQuestion has Dated DirObject at anytime in the past. If so, it yields a "yes"; if not, it yields a "no".
Here's another example: suppose that we want to allow the gal's brother to intervene when a guy tries to kiss the gal. Suppose further that we do not keep any specific record of brotherhood status, but we do keep two other items of information: Kinship and Maleness. Thus, we can look up how closely related CharacterInQuestion is to the gal, and we can look up whether he's a he or a she's a he or whatever. Here's what our role definition would look like:
This formula first looks at the Kinship of DirObject and CharacterInQuestion, and if that Kinship is greater than 10, we presume that they are siblings. Then we ask about the maleness of CharacterInQuestion. If we get a "yes" to both questions, ("Yes, kinship is greater than 10, AND yes, CharacterInQuestion is male"), then we declare CharacterInQuestion to fit the role.
I could build even more complex examples but I think you can see that we can take this concept as far as we wish. The important point is that the concept of the role definition affords us vast expressive power in the articulation of the precise dramatic roles played by different characters.