The Comme il Faut Asset
In most scenarios that are focused on social interaction it is likely there will be various social conventions that agents should follow such as introducing themselves in the beginning of a conversation or saying goodbye at the end.
The purpose of the CiF-CK component is precisely to make agents aware of this existing social exchanges as well as capable of executing them appropriately. The main motivation is to be able to automatically add a layer of social behavior that can be reused across several domains.
The original “Comme il Faut” architecture was created by James McCoy and Michel Mateas and it was implemented in the video game “Prom Week”, whose gameplay and architecture cycle is shown in the figure below:
This architecture was the basis for a new project whose objective was to implement it on a popular and commercial video game.
The video game chosen was The Elder Scrolls V:Skyrim. and the resulting architecture was called: CiF-CK: An Architecture for Social NPCs in Commercial Games. Its implementation was released as a free online modification (mod) for the game called “Social NPCs” and it had quite a bit of success with over 6 000 different players in its first 40 days.
The desire to continue the work on the CiF-CK architecture led to its integration within FAtiMA Toolkit as a module that, while it works independently, has great synergy with the other ones.
CiF-CK and FAtiMA
In CIF-CK the architecture had 4 major key components:
When making the transition to FAtiMA we noticed that several of these components were already defined within the architecture.
For example, the characters are now called Role Play Characters where CiF-CK exists as a reasoner component that helps RPCs in its decision making or appraisal process.
At first glance it might seems has been reduced to playing a small part within FAtiMA. However all of its elements can be mapped to the current FAtiMA Architecture. Let’s start with the Characters, now they become Role Play Characters.
This small change actually causes quite a significant difference when taking a look at the architecture. In FAtiMA actions are selected by the Emotional Decision Making asset according to their conditions and with the beliefs of the RPC they are inserted in. They are not independent entities and they can be different for different characters, as such:
In the original CiF, the social state of the world was captured by four different representations: Social networks, Relationships, the Cultural Knowledge Base, and the Social Facts Knowledge Base. In CiF-CK we reformulated the Social State and it only contained only two of those elements: the Social Facts Knowledge Base and the Relationships.
The Social Facts Knowledge Base is essentially the Social history of the world and it was stored as a static reference and accessible to all characters. In order to avoid straining the game engine, in Skyrim, characters only remembered the last 10 exchanges that happened around them. The Relationships component of the Social State was a simple database that kept all the recognised public relationships it was also stored a static reference and accessible to anyone.
Because FAtiMA is a character-focused architecture suddenly there is no need to have a Social State entity. We might refer to it but in truth it is the characters themselves. Because characters themselves have a autobiographic memory they can store all the relevant events themselves. In turn, the Relationship component also becomes obsolete, if developers want they can create their own database but it is unessential in FAtiMA’s architecture.
The performance of each action is left to the video game developer, it is heavily dependent on the graphics, game engine, types of characters and too hard to generalize. We do provide some tools for developers might ease this process. For instance, if it is a dialogue based interaction you might use our Dialogue Editor. It received EDM’s actions and transforms them into dialogues and even provides text-to-speech.
All that is left are the consequences of each action and the Trigger Rules. Trigger rules account for social changes that result from multiple social games and other elements of the social state. For example, a character will receive the status of “cheating” after starting a relationship with one character when they are already dating someone else.
The consequences of each action and their cascading effect, the Trigger Rules, are the reason for the development of the World Model. This component can manage the consequences of each action transform them into events and then inform the characters of the events each is to perceive. This is the end result:
Let’s now take a look at how CiF-CK really works within FAtiMA.
The primary knowledge structure of CiF-CK are Social Exchanges. These are meant to represent an established sequence of interaction steps between two agents. As such, in FAtiMA they are defined as the following tuple:
<name, target, steps, conditions>
Name is used to identify the type of social exchange (e.g. Flirt, Greet)
Target is the name of the agent with whom the social exchange is to be performed with.
Steps is a list of symbols that represents the sequence of actions that both agents perform in a back and forth manner (e.g. Initiate, Answer, Finalize).
Conditions are logical conditions that can be of two types:
- Starting-conditions: used to define when a Social Exchange can start.
- Mode-conditions. used to compute the desire an agent has to perform a specific social exchange in a certain mode. As such, each mode-condition has the name of the mode it refers to (e.g. Positive, Negative, Sarcastic) and it also has a value associated with it.
The desire for the agent to perform a step of the social exchange using a particular mode is given by the sum of the values of all its mode-conditions that are verified and the resulting value is what we call the Volition.
The social exchanges that are defined in the CiF-CK component can be used in decision rules through the following meta-belief:
This meta-belief will automatically find valid substitutions for the defined variables and return a numerical value representing the desire of the agent to perform a specific step of a social exchange in a certain mode.
For example, the value of Volition(Flirt, John, Initiate, Sarcastic) is determined by first checking if the starting conditions of the “Flirt” social exchange are verified and the
current step in the execution order is “Initiate”. If all this applies, the algorithm then sums and returns the value of all the “Sarcastic” conditions that are verified. The returned value can then be directly linked to the priority of the decision rule that uses this meta-belief.
Note that there is a synergy between the CiF-CK and Social Importance component as it is possible to use conditions based on SI in the conditions of a social exchange.
Using CiF-CK within the Authoring Tool
Let’s open its .iat (Integrated Authoring Tool) file using the Toolkit:
As you can see in the “CIF” tab there are only 2 different Social Exchanges. A “Sport” and a “Univ” SE. If you press the “Edit” button you can see that each one has 3 different “Steps” : “Initiate, Answer, Finalise”. Additionally you can also see their starting conditions below. The “HasFloor” belief is one we usually use to define if a character can talk or not. If they believe they have the “Floor” then they talk.
In the current version of the Toolkit the mode conditions can be seen in the “Influence Rules Inspector”. Each rule within this inspector has a “Mode” and “Value” associated with it. In this examples we did not use any modes.
When the Sarah agent is deciding if she wants to perform the Univ Social Exchange she will start by evaluating its starting conditions:
GoesToUniversity([t]) = True Has(Floor) = SELF
Does the target go to the University and does Sarah have “Floor” in the conversation. If these are true then Sarah will check its Mode Conditions, in this case:
Presentable([t]) = True WantsTheJob(SELF) = True
As there is no particular mode associated to them Sarah will evaluate both, however, the second condition does not apply to her. It will be used when the Player himself is deciding. As such, if the Player is presentable (defined in the knowledge base) then Sarah will want to perform the “Univ” Social Exchange with the Player as a Target with a Volition value of 5.
The Volition Meta-Belief
In FAtiMA Toolkit we use meta-beliefs as knowledge produced by affective or reasoning processes. Similar to a regular belief, its syntactic structure is a composed name with a root symbol and a sequence of literals within parenthesis that are separated by commas. The difference is that metabeliefs are registered in the Knowledge Base as procedures with their name becoming a reserved keyword.
The Comme ill Faut reasoning process is reserved to the “Volition” keyword. As we mentioned before, Volition represents how much does an agent want to perform a particular Social Exchange. This value is the sum of every “True” Mode Condition.
In the Demo example the Meta-Belief is used in the conditions of Sarah’s only Emotional Decision Making Action Rule as seen in the image below:
- [x] : is the Target if the Actions
- [cs] : is the Current State of the Speak Action
- [ns] : is the Next State of the Speak Action
- [se] : is the Name of the Social Exchange
- [step] : is the Step of the Social Exchange
And now each condition:
- “Has(Floor) = SELF” : If this agent has the floor.
- “IsAgent([x]) = True” : If the agent believes [x] is an agent.
- ” ValidDialogue([cs], [ns], SE([se],[step], * ) = True ” : If there are dialogues available in this scenario with valid substitutions for each of the variables.
- “EventId(Action-End, *, Speak([cs],[ns],[m],*) [x] ) = -1” : If the action “Speak([cs],[ns],[m],*)” has not happened before.
- “Volition([se], [step], [x], * ) > 0” : If the Volition to perform Social Exchange [se] for the Step [step] is positive.
Let’s now take a look at how the unification algorithm works in this particular case when Sarah has the following beliefs:
Note that other substitution “branches” occur but we chose to only represent these, as they are the most relevant.
Next we will take a look at how the Toolkit handles conversations and scripts with the Dialogue Manager