Understanding the Mary and Bob story

In order to demonstrate the use of the DGiovanni architecture, together with the distribution it is included a story implementation called Mary and Bob.

Mary and Bob is an one-act story, consisting of two scenes. Three ends are possible: (1) The player is expelled by Bob, (2) the player is expelled by Mary, and (3) the player flees covered in blood. You can see some screenshots of the Mary and Bob story here. If you want to know how to play it, see the Revealing the Mary and Bob story section. Besides, the sections Mary and Bob story - example 1, Mary and Bob story - example 2, Mary and Bob story - example 3 and Mary and Bob story - example 4 show some variations of the Mary and Bob story. Note, however, that there are several others that may occur depending on the player interaction.

The figure 1 shows the abox of the Mary and Bob story. This abox is used to feed the system with story-related information (e.g. what a character is wearing), to define the location of JAVA classes that are loaded through reflection, to define the location of the asl files that contain the characters' behaviors and, finally, to define the location of the asl file where the beats are coded.

Figure 1: The abox of the Mary and Bob story

The story's structure is represented by the main structure asl file (i.e. the beat_sequencer_agent.asl file) whose fragment is shown in the figure 2. After processing the ontologies, the story-related information is added to the environment's lists of percepts of the agents, being subsequently added as beliefs to the belief bases of the characters and of drama manager. The addition of the "act(1,apartment)" belief to the belief base of the drama manager triggers the "+act(1,apartment)" plan defined in the beat_sequencer_agent asl file, and hence starts the story. As can also be seen in the figure 2, the information added to the belief bases of the agents (e.g. information about a scene, the age of the characters, etc. ) is retrieved to be printed in the GUI.

Figure 2: Beginning the Mary and Bob story

In the Mary and Bob story, it is considered a beat every plan with the word "beat" as functor and behavior every plan with the word "behavior" as functor. The beats are coded into the beat_sequencer_agent asl file. Every beat consists of a collection of behaviors. The story consists of at most eight beats. The table 1 shows the beats of the Mary and Bob story.

Name	Minimum Tension	Maximum Tension
At the door of the apartment	+0.0	+1.2
Receiving the player	+0.0	+0.2
Offering drink	-0.1	+0.4
Bob suggests going to a massage parlor	+0.2	+0.9
Mary makes advances to the player	+0.3	+1.5
Making the player go away	+0.6	+1.3
Fleeing	-4.9	-4.9
Finis	+0.0	+0.0

Table 1: The beats of the Mary and Bob story

The beats and the behaviors also have annotations attached to themselves. Every beat has as annotations an "id", a "name", a "min_tension" (the minimum tension that the beat can add to the story.), and a "max_tension" (the maximum tension that the beat can add to the story). On the other hand, each behavior has as annotations an "id", a "name", and a "significance" value (the quantity of tension that the behavior adds to or subtracts from the beat). The figure 3 shows a fragment of the beat Offering drink.

Figure 3: The start of the beat Offering drink

As can be seen in the figures 4, 5 and 6, the real implementation of the characters' behaviors appear at their asl files. In this sense, the beat_sequencer_agent asl file is used by drama manager to command the execution of the behaviors defined at the asl files of the characters.

Figure 4: Examples of Player's behaviors for the beat Offering drink

Figure 5: Examples of Bob's behaviors for the beat Offering drink

Figure 6: Example of Mary's behavior for the beat Offering drink

The drama manager receives messages and perceives percepts in the environment (e.g. caused by a knock on the door) in a format of a behavior belief that represents the way that the Player has behaved in a particular situation. Based on the interaction with the Player it decides how the non-player characters (NPCs) should react. To simplify the process, all messages that the Player addresses to the NPCs are being redirected to the drama manager itself. In this case, the drama manager has all the power to decide how the NPCs must react.

The story implementation supports four types of input. The first type are the actions realized in order to affect the environment or character(s). The figure 7 shows the generated percept that is added to the environment for the action of knocking on the door.

Figure 7: The generated behavior percept for the action of knocking on the door

The second type of input is the textual input. The figure 8 shows an example of generated behavior belief for a textual input.

Figure 8: Example of generated behavior belief for a textual input

Looking carefully the figure 3 you can see the definition of a plan to handle the addition of this belief (i.e. behavior(player,bob,discourseAct(drink,player,beer),"I want beer")) to the belief base of the drama manager (see the @behavior_agreeing_drinking_sth_alcoholic_informed_with_subject).

The third type of input is the emoticon. The figure 9 shows an example of generated behavior belief for an emoticon input.

Figure 9: Example of generated behavior belief for an emoticon input

The last type of input is the textual input accompanied by an emoticon conveying a similar idea (or not). The figure 10 shows an example of generated behavior belief for a textual input accompanied by an emoticon.

Figure 10: Example of generated behavior belief for a textual input accompanied by an emoticon

But what happens when the player's input consists of a textual input accompanied by an emoticon that contradicts the idea communicated by the textual input? The figure 11 shows an example where the player said "no" to the drink offer but signaled the contrary with his hand. Note that the character Bob reacted to this input in a different way.

Figure 11: Example of generated behavior belief for a textual input accompanied by an emoticon that contradicts it

For the Player's input to be considered by the drama manager, this input must first be transformed conveniently. In the case of a textual input, the system tries to map the given input to a discourse act. This mapping is accomplished by applying some rules that consider some information generated by the Stanford Lexicalized Parser (e.g. grammatical information in general, typed dependencies, etc.) after parsing the input sentence, and a XML file that maps words and emoticons to discourse acts. The figure 12 shows a fragment of this XML file. Besides, the definition of the discourse act that maps to the given textual input may also depend on factors such as the context of the beat, if there is a negation in the sentence, etc. When the input is an emoticon just the XML file is considered.

Figure 12: Example of discourse act in the Mary and Bob story