Types of conditions

This section describes the several types of conditions that can be used in goal’s preconditions, failure and success conditions. Additionally it also depicts the restrictions that exist for each type of condition. All types of conditions must implement the FindSubst function.

Property Conditions

Property conditions represent conditions about an object or world property, a relation or even a condition between variables and constants. For instance the property “Luke(strength)” represents Luke’s strength property, and “Like(Luke,John)” represents the interpersonal relation of like/dislike between Luke and John. This type of information is named semantic information and its stored in the KnowledgeBase. Thus, property conditions are tested against the agent’s KB.


<Property name=”[target](strength)” operator=”LesserThan” value=”[SELF](strength)”/>


<Property name=”[target](owner)” operator=”=” value=”[victim]“/>


<Property name=”[victim]” operator=”!=” value=”[SELF]“/>


<Property name=”Like([x],[y])” operator=”GreaterThan” value=”0″/>


These are examples of several property conditions. Property conditions are extremely versatile because they allow specifying conditions between two properties, between a property and a variable, between a property and a constant, between variables and even between constants. In fact, the name property condition is only due to the original intention of using this type of condition to model properties. However, property conditions are far more powerful. To define a property condition it’s mandatory to define three attributes:

  • name – Well formed name representing the condition that is tested
  • operator – Operator used to determine the truth value of the condition
  • value – value used to compare the property to (another well formed name)


There are four types of operators used in a condition “a operator b”:

  • GreaterThan: the condition is true if the value of a is greater than b’s value
  • LesserThan: true if a’s value is lesser than b’s value
  • =, true if a and b have the same value
  • !=, true if a and b have different values


The first two operators can only be applied to numeric values, where the last two can be applied to either  number or names.




The function FindSubst applied to a property condition searches the KB for the condition’s truth-value. If the property contains any unbound variables (ex: [x]), the function tries to match the left side with all knowledge stored in the KB. If the match is successful, the process is applied to right side of the property condition. All possible values are then filtered, returning only the substitutions that make the property condition true.


Nevertheless, != conditions are not determined in the same way. Initially, it starts by matching the left side with all the knowledge stored in the KB. For each possible substitution, the left side is compared with the right side and the substitution is considered valid if the comparison fails. As example, consider the following property condition:


<Property name=”[target](type)” operator=”!=” value=”character”/>


Consider also that the following facts are stored in the KB: book(type) stores the value “object”; ball(type) stores the value “object”; John(type) stores the value “character” and Luke(type) stores the value “character”. Matching the left side of the condition against the KB returns the following set of substitutions {{[target]/book]},{[target]/ball},{[target]/John},{[target]/Luke}}. Afterwards, for each substitution, the value of the property is compared with the condition’s right side and only the substitutions that satisfy the inequality are returned. In this example, the condition test returns {{[target]/book]},{[target]/ball}}.


There is an important restriction when using != conditions: if the right side of a != condition its not grounded (contains a unbound variable) its not possible to determine the possible range of substitutions for it, therefore in these situations, the condition test  automatically fails. Therefore, when defining goal’s preconditions, you should make sure that != conditions are tested only after the variables used in the right side are instantiated by previous conditions.


Recent, New and Past Event conditions

With regards to FAtiMA’s previous version, before the implementation of the computational autobiographic memory, all of an individual agent’s knowledge was stored in a general knowledge base. However, this knowledge base was designed to store semantic information and events stored in it refer to facts occurred in the current episode, e.g. “EVENT(Luke,push,John)”. Therefore it was impossible to distinguish between events that just occurred and events experienced by the agent a while ago. With the integrated autobiographic memory, there is now a clear separation between different types of information, e.g. events and related actions are stored in this memory, and world properties and agent relations are stored in the knowledge base.


Recent Event conditions are thus used to test if a given event has happened in the current episode. This is achieved by searching for the event in the current active Episode in the Autobiographical Memory. Past event conditions are very similar to Recent event conditions, but instead of searching for the event in the current episode, past event conditions search in older memory episodes. There is a third type of event condition, the New Event condition, which tests if an event occurred within a very short time distance. This is useful, for instance when you want to specify a goal with a success condition that is repeated several times. When a RecentEvent condition is used, the condition will be true for some time after the goal succeeds, which will make it impossible for the goal to become active again.

The following conditions are examples of recent event,new event and past event conditions.


<RecentEvent occurred=”False” subject=”[SELF]” action=”Reply” target=”[friend]”



<PastEvent occurred=”True” subject=”[SELF]” action=”cry”/>


<RecentEvent occurred=”True” subject=”[target]” action=”SpeechAct” parameters=”insult”/>


<NewEvent occurred=”True” subject=”[target]” action=”SpeechAct” parameters=”insult”/>
The sintax for these Recent event, New Event and Past event conditions only differs in the name used to identify the condition type. Recent event conditions start with “RecentEvent”, while Past event conditions start with “PastEvent” (and the corresponding for New event conditions). Everything else is identical. An event condition is defined by the following attributes:


  • occurred – this attribute specifies if the event conditions tries to verify is a given event has happened or if the event has not happened. Its not mandatory to define this parameter because by default, it has the value “True”, which means that the condition tests if the event has happened. Therefore, the two positive examples shown above could be defined without expressing “occurred=”True””.
  • subject – this attribute is mandatory and specifies the subject who performed the event that the condition is searching for. Unlike the definition of events used for reaction rules and action tendencies, the symbol “*” cannot be used to express that any subject will match with the condition.  If the author wants to express such condition, he can use an unbound variable (ex: subject=”[s]”) that can in fact be matched with any subject but has the additional advantage of allowing the use of the same variable in order to relate the subject of the event to other preconditions and success conditions.
  • action – this attribute is mandatory.
  • target – the target attribute is not mandatory, mainly because there are events that do not have a target (as in the second example shown above). Nevertheless, if the event specified in the condition does contain a target, it’s necessary to define the target attribute. If the target is not defined, the condition will not work. For the same reasons as in the subject parameter, the symbol “*” cannot be used to express that any target will match with the condition.
  • parameters- the last attribute defines the parameters of the event, if they exist. Similarly to the target parameters, this attribute is not mandatory, because many events do not have parameters. This attribute consists on a list of comma-separated parameters, and each of them can use an individual variable. Unlike the previous attributes, the symbol “*” can be used for one or more parameters to express that the event will satisfy the condition independently of the specific value of that parameter (similarly to the definition of events for reaction rules and action tendencies. However, there is one restriction: even if the parameters are undefined (by using “*”), it’s necessary to write all parameters that the event may contain. For instance, if the event would contain 2 parameters, one should write parameters=”*,*” instead of parameters=”*”. Despite this functionality, if the parameters are defined as “*” its not possible to use them in other preconditions and in the goal’s failure/success conditions, therefore its always advisable to use variables instead of “*” (ex: parameters=”[x1],[y1]” instead of parameters=”*,*”).



Applying the function FindSubst to a recent event or past event condition corresponds to searching in the current (for recent events) or remaining (for past events) memory episodes stored in Autobiographic Memory for an event that positively matches with the condition.  If the condition specifies occurred=”False”, the method checks if the specified event does not exist in memory.  


Similarly to negative property conditions, if a negative event condition (occurred=”False”) contains any unbound variables, it is not possible to determine the possible range of substitutions for it, therefore in these situations, the event condition  automatically fails. Therefore, when defining goal’s preconditions, you should make sure that negative event conditions are tested only after the variables used are instantiated by previous conditions.


Emotional State Conditions

Emotional state conditions allow the specification of conditions over the character’s internal emotional state. Thus, the author can use them to trigger goals based on specific emotions:


<ActivePursuitGoal name=”UnleashFury([x])”>


<EmotionCondition emotion=”Anger” min-intensity=”3″ target=”[x]” />



<RecentEvent occurred=”True” subject=”[SELF]” action=”push” target=”[x]” />




This example shows a goal that is triggered when the agent feels angry with at least intensity 3 towards someone. The goal consists in pushing the agent that is causing his anger. An emotional state condition is defined by the following attributes:

  • active – states whether the condition is testing if the specified emotion is active in the emotional state or not. By default, active has the value “True”, thus it’s not mandatory to define this attribute. If its necessary to specify a condition that tests if the character does not feel a given emotion, one should write active=”False”.
  • emotion – the type of emotion that the condition searches for. This attribute is mandatory and must be one of the twenty-two emotion types defined in OCC (Joy, Distress, Anger, etc).
  • min-intensity – the minimum intensity that an emotion of the defined type must have in order to satisfy the condition. This field is not mandatory, if left undefined, it has the value 0 by default.
  • target – Some, but not all emotions are directed towards someone. In these cases, the target attribute allows to retrieve or test the target of such emotions.




The FindSubst function for emotional state conditions is extremely simple. It searches for the specified emotion in the agent’s emotional state, and it tries to find at least one with intensity equal or greater than the specified minimum value. If the target of the emotion is relevant (as in the case of the above example) for the condition, the function returns all targets corresponding to valid activated emotions. For instance, if the character would experience anger towards Luke and Paul, two separated emotions, the above goal would create two intentions: one to push Luke and another to push Paul. If the target is not relevant, the function just returns true or false independently of the number of active emotions that match the condition.


Negative emotion conditions work by checking if the specified emotion is not in the emotional state. For instance, the next example shows a condition that is verified if the agent does not feel a distress emotion with intensity equal or greater than two.


<EmotionCondition active=”False” emotion=”Distress” min-intensity=”2″ />


For the same reasons as property conditions and event conditions,  if a negative emotion condition (active=”False”) has an unbound target, it is not possible to determine the possible range of substitutions for it, therefore in these situations, the emotion condition  automatically fails. Therefore, when defining goal’s preconditions, you should make sure that negative emotion conditions with an unbound target are tested only after the variable used for the target is instantiated by previous conditions.