Emotionally Responsive Robotic Avatars as Characters in Virtual Worlds

Stuart Slater University of Wolverhampton

UK s.i.slater@wlv.ac.uk

David Burden Daden Limited

UK david.burden@daden.co.uk

Abstract

This paper presents recent work on the addition of emotions and affective behaviour to robotic avatars within Second Life, as part of continuing research and development in the area of interactive agents for games and simulations. The development is based upon the E-AI architecture [1] which is a proposed computational model of emotions intended to be used by developers who already have their own agent AI systems. In this work, the E-AI architecture was applied to a currently existing commercial AI and chatbot architecture.

Keywords – Virtual Worlds, Emotion Modeling, AI

I. INTRODUCTION Whether the user is interacting with a role playing game,

simulation or web e-commerce application, the evolution of interactive technologies will mean they are likely to encounter a “software agent” in one of many guises. The first type of agent could be a non-player character in a role playing game, which the user will probably approach in order to progress in the game. This character will most likely be a “humanoid looking” in-game character that will provide a service to them, or be able to direct them on how they might complete a quest from a range of possible clickable options such as those found in games like the World of Warcraft1. The second type of agent could be a similar character in a simulation where the user walks over to a virtual instructor/trainer, who gives them an objective like “treat an injured member of the public”, and later the user can ask questions and receive pre-scripted responses to help them train or learn how to do something that may be impractical, dangerous or expensive to do in real life. The third kind of agent might be a user interface on one of the many e-commerce sites such as Amazon that can suggest products based on previous experience of the user and be able to guide the user on how they might complete their transaction.

Whatever the “software interface” that helps the user, the important consideration is that the user should not only find the interface helpful, but also interesting to use so that they might be more likely to return and use it again. One aspect of agents thought to contribute to interesting and engaging experiences is agents with emotional characteristics and responses [2]. Therefore with a lack of emotionally enhanced agents in the area of commercial games, simulations and the web, a project

1 www.worldofwarcraft.com

was undertaken to add a limited set of emotions to a pre-existing chat-bot in Second Life in order to evaluate the bot’s changing behaviour, and the user's response to the enhancements.

II. SECOND LIFE OVERVIEW Second Life is an interactive 3D virtual world developed by

the Linden Lab2. The application, allows users to create a character (usually referred to as an avatar) that they are able to navigate around a variety of virtual environments interacting with other users’ avatars or objects. Each user can only enter the world through their avatar, but are free to customise their visual appearance so that they can resemble almost any person or in fact any thing as shown in Fig. 1.

Whilst in the virtual world, users typically move their avatars around using a range of methods such as walking, flying or a teleport mechanism which allows users to visit distant locations. When another avatar is encountered, users are free to talk through voice or textual chat and carry out a conversation as they would with any other real person. Upon encountering some objects, users are able to interact with them depending on their in-world purpose, which is defined by the author. These uses can include redirecting visitors to other locations and opening up external internet links.

Figure 1. Typical Second Life Avatars

2 www.secondlife.com

2009 Conference in Games and Virtual Worlds for Serious Applications

978-0-7695-3588-3/09 $25.00 © 2009 IEEE

DOI 10.1109/VS-GAMES.2009.7

12

2009 Conference in Games and Virtual Worlds for Serious Applications

978-0-7695-3588-3/09 $25.00 © 2009 IEEE

DOI 10.1109/VS-GAMES.2009.7

12

2009 Conference in Games and Virtual Worlds for Serious Applications

978-0-7695-3588-3/09 $25.00 © 2009 IEEE

DOI 10.1109/VS-GAMES.2009.7

12

2009 Conference in Games and Virtual Worlds for Serious Applications

978-0-7695-3588-3/09 $25.00 © 2009 IEEE

DOI 10.1109/VS-GAMES.2009.7

12

This combination of interactive communication and flexibility in world design, provide a platform for a range of applications including, social networking, delivery of academic material, virtualisation of art3, e-commerce and training.

III. DIMENSIONS OF INTERACTION IN SECOND LIFE Text chat can often lack engagement as human beings also

communicate with their eyes, and passively observe faces and postures in order to build relationships and relate to other people. Within Second Life this is partly addressed by being able to see a virtualised user who can also make their avatar show a range of gestures as shown in Fig. 2.

Figure 2. Generic gestures, text triggers and short cuts

For users who may require a more expressive avatar, then Second Life features the ability to add or customise gestures based on developer skill. These gestures, and text or speech can be combined by the user to form the communication interface for their virtual presence. Users can combine:

• Animation – What their avatar does when prompted, these can be modelled in packages such as Poser4.

• Sound – A suitable sound that will come from their avatar during the gesture.

• Chat – Text can be displayed when the gesture is activated.

• Wait – Allows different delays to occur between animations, chat or sounds.Once a new gesture has been created, it can be added to the user’s avatar and can be subsequently activated by using a suitable short cut key or by typing a shortcut into the speech bar preceded by a forward slash.

IV. CORPORATE GREETER AVATARS One of the applications of Second Life has been as a

marketing and communications platform for a range of companies, and as an e-commerce platform supporting in-

3 www.slartmagazine.com/ 4 http://my.smithmicro.com/win/poser/index.html

world businesses which create and sell objects and avatar clothing and enhancements to other users. To support such activities, some organisations have avatars at their virtual premises (often called greeters) which are controlled by members of staff. These staff members, through their avatars, are able to answer questions when approached by visitors and allow prospective customers to ask in much more detail about the questions or issues they may have, or to gain a better understanding of the company or services available. However this is not normally a cost-effective approach.

V. COMPUTER CONTROLLED AVATARS (ROBOTARS) A growing area of interest in virtual worlds such as Second

Life is the ability to create an in-world avatar, and control it externally with some type of automated intelligent software – such as a chatbot programme to emulate human conversation. These computer controlled avatars (often referred to as bots - short for robots, or robotars – a contraction of robotic avatars) can have many forms, but in essence can provide a level of autonomy to the bot such that it can conceivably pass initially as a human controlled avatar (see Fig. 3).

Figure 3. Halo an evolving chat-bot

The advantages of such a bot are numerous including being able to have a 24hr/365 days a year presence that can answer questions and of course does not need paying. Limitations include: the need for a continuous connection to the avatar from the remote computer, the fact the bot can only deal with known questions that have been pre-programmed, and the risk that some users may be offended if they engage in conversation with a bot thinking it is a real human user (so bots are often flagged with labels such as “robotar”). Users interacting with the chat-bot may not always instantly recognize that they are in fact talking to an automated piece of software, though after a short conversation it is generally quite easy to realize that something isn’t quite right, and asking something outside of the limited programming, reveals the identity of a chat-bot (each conversation potentially being a mini-Turing test) [3].

13131313

Understandably commercial/educational use is not focused on recreating a perfect mimic of a human being, but instead is focused on meeting the users needs and as such the limited facilities in many robotars makes them fit for purpose, though often not very engaging - users looking for more human or sophisticated interaction may well look elsewhere. In order to address this issue there is an interest in incorporating emotions into robotars to increase the levels of engagement and interest from the user.

A. Robotar Architecture The fact that Second Life does not natively support robotars

means that there is a reliance on third party developers to develop their own back end technologies to control the avatar’s behaviour including movement and chat, and interface it to Second Life via a suitable interface. One such robotar system developed by Daden Ltd5 is called Altair, and is shown in Fig. 4.

Figure 4. The Altair robotar architecture

The main components of Altair are:

• The Second Life servers, which manage the in-world interactions of the users, and pass each client (user’s PC) details of what is around them in the Second Life world.

• Libsecondlife6, an open source library of code (C#/.NET) which resides on a client machine, and is capable of connecting to Second Life as though it was an ordinary user account. Libsecondlife has been developed with an easily accessible application programming interface (.NET API) that can be used to control the Second Life avatar from code rather than direct human control, thus converting an avatar to a bot. This requires developers to write their own bot control software.

5 www.daden.co.uk 6 www.libsecondlife.org

• BotIF, the bot control software used to interface to libsecondlife. It is based on a web service API incorporating both an Avatar Action Markup Language (AAML) and an Avatar Sensor Markup Language (ASML). Both AAML and ASML have been developed to provide increased functionality and behaviour in a new generation of cross platform bot architectures, that only require new bot interfaces to be developed each the virtual world. ASML provides a markup for what the avatar senses (e.g. things being said to it, objects or avatars moving near it). AAML is used by the bots higher level functions (which read the ASML input) to specify what the bot should do (move, say, give, gesture etc).

• Altair core code, which co-ordinates the plug-ins that provide higher level functions such as chat (using Daden's Discourse chat engine), emotions (the subject of this paper) and navigation. Altair code is currently split between code on the interface PC for low-level/fast-response functions, and web based code for higher level functions.

B. Gestures and Robotars The addition of gestures, combined with the ability to

control an avatar through code, means that bots can be programmed to mimic many human behaviors such as stepping back when faced with something unexpected or to show a shocked expression if inappropriate chat is being received from a user. In the same way as avatar gestures are a combination of animation, sound, text and delays, so bot gestures can be developed the same way. One clear difference is that instead of needing a manual key press or text prompt, bots can be programmed as part of the remote AI software to blend conversation, movement and gestures together to appear more natural in conversation than avatars controlled by users.

VI. THE E-AI ARCHITECTURE The E-AI architecture, used as the basis for the emotions in

this project, has been specifically developed for researchers who may not wish to tie themselves into one of the currently available cognitive architectures such as CogAff7, Emile8, SOAR9 and Tok10 that traditionally combine their emotion components into the agent’s primary cognitive model. Each of these architectures has proven merits and strengths, but traditionally commercial developers use in-house libraries to fulfil agent behaviours and as such need guidance on how emotions can be incorporated into their own software solutions. With this in mind E-AI is grounded in formal psychology and includes salient aspects of common architectures to provide guidelines and a specification to developers in the broad area of emotions. It brings together non-conflicting theories of emotion and clarification to much of the common terminology, such as

7 www.cs.bham.ac.uk/research/projects/cogaff/ 8 www.isi.edu/~marsella/webpapers3.html 9 www.sitemaker.umich.edu/soar/soar_at_um 10 www.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/papers.html

14141414

moods, feelings and emotional categories [4]. The architecture is built around the six stage emotional process [5] as shown in Fig. 5.

The E-AI architecture is intended to make use of the pre-existing systems already in place in many games and simulations (agent cognitive, behaviour and detection systems). These systems need to be supplemented with a few additional variables and some code to implement both the fuzzy logic and finite state machines (FSM) used to appraise the agent’s emotions.

Figure 5. E-AI six stage emotion process

A. Previous Applications of the Architecture In previous work the E-AI architecture was applied to

combat bots in Quake 3 (see Fig. 6). The work undertaken, involved the addition of A.I. enhancements to the bots in the Quake 3 game to provide them with a limited set of emotions and evaluate their performance within a typical combat game environment.

Figure 6. Quake 3 game screen, showing user attacking bot enemy

Using the software development kit available under a GNU public licence, and some design tools such as GTK Radiant, researchers are able to create scenarios and alter the behaviour of bots in the game so that they are able to:

• Observe bots that can work together in a limited capacity to defeat the player, with the capability to alter the bots behaviour.

• Allow multi-users to control avatars and compete in a range of custom battles against each other or bots.

• Be able to place ready made objects into the environment and observe, and alter the agent decision making process (a fuzzy logic approach) related to the objects.

• Create almost any custom environment or interface for the interaction.

The task of applying a small range of basic emotions to the bots, was achieved by encoding additional finites state machines and fuzzy logic to interface to the pre-existing goal system present in the AI libraries (provided with the SDK).

The results from this work clearly supported the assumption that the emotionally enhanced bots, performed less well in combat situations. These bots in over 300 combat situations involving the death of another bot are getting around 20% less kills, and are winning a below average number of matches, in fact almost half as many matches as the other bots. Looking at the e-Bot’s behaviour log, this lack of combat effectiveness was partly attributed to the e-Bot running away from combat situations when experiencing fear, and often froze for a second (startle response) when an attacking bot came round a corner. The Quake 3 e-Bot results fed into both the E-AI architecture and into the work presented here in order to improve its applicability to non-gaming architectures.

VII. APPLYING THE E-AI ARCHITECTURE TO ROBOTARS The E-AI architecture discusses both a fast reaction

mechanism called the low road [6] and a slower more considered processing mechanism called the high road [6].

5. Motivation to Act

4. Physiological Changes

3. Unconscious Reaction

2. Appraisal of Stimulus

6. Conscious Realisation (Feelings)

1. Detection of Stimulus (Perception/Sensation)

Specific to the particular target application. How the emotionally enhanced agent detects changes

to their environment, other agents or objects including line of sight algorithms (LOS). An

additional variable is needed which signifies if the stimulus is showing a visible emotion. Everything

detectable needs a unique Stimulus ID.

Database The stimulus is checked against the emotional alert database which contains details of stimulus, related emotions, and some memory facilities. These are

used with both finite state machines and fuzzy logic, in order to ascertain any emotional significance.

Not modelled Traditionally this is blood pressure changes etc.

Animation Depending on the emotional appraisal:

• Agent facial emotion changes. • Body Posture changes. • Agent may move slightly, towards or

away from stimulus.

Behaviour (Goals and Actions)Based on the emotional appraisal the agents

goals and actions will be re-evaluated based on what emotional state they are in.

Textual Storage The current stimulus, emotional appraisal,

animation, and behaviour are stringed together toprovide strings that can be queried in order to

ask the agent how they feel.

15151515

When initially mapping E-AI to the Altair and Second Life infrastructure, it became apparent that any fast processing would need to be done in BotIF, locally to where libsecondlife is running, in order that the latency between information sending and receiving is minimised. Any other more processor intensive processing will be done remotely and the data/information transferred to Altair via a suitable web service.

A. Detection of Stimulus When libsecondlife is used to access the Second Life

server, the API receives exactly the same information as the standard Second Life client, but in a form that can be used as part of a programming solution. The bot itself is merely a collection of variable checks and responses and as such the bot’s domain knowledge and cognitive model need to be shaped by the developer based on the data received. This data typically includes:

• Information on the location, actions and appearance of other avatars

• Information on the location, shapes, textures and actions of objects

• Information on in-world interactions (e.g. When another avatar says something or gives something)

This data is received by libsecondlife and passed to BotIF.

BotIF tracks changes to objects and avatars within the simulator (sim) the bot is currently on (a virtual area of 65536 sq m).

In the implementation discussed here, bots were only programmed to actually respond to stimuli within 50m and only on the “root” object (which contains name and other data) of multi-prim objects (all objects in Second Life are constructed from primitive shapes – usually shortened to “prims”).

B. Appraisal For stimuli of interest BotIF flags any significant changes

to one or both of:

• The E-AI surprise and startle function running locally.

• The main Altair AI engine running remotely, by way of the ASML sensory mark-up and web service mentioned previously.

1) Surprise and Startle Appraisal

As mentioned above, given the speed of response required of the surprise and startle module, it was decided to run the code locally alongside BotIF, rather than on the server at the end of a web services call. When BotIF is started the Emotional Alert Database (EAD), which specifies emotionally significant stimuli, is loaded into memory to ensure quick response and to track stimulus adaptation.

The steps within surprise and startle are:

• Check the name of any newly detected object within threat range (typically <5m), against the Emotional Alert Database (EAD) for any fear response. If found then response = fear.

• Gather situational information about the object such as, behind, moving, previously detected etc.

• Based on this data, and the entry in the EAD activate the appropriate startle, surprise or shock response.

• Pass the final response to the Emotional Response Module (ERM).

• Apply the relevant stimulus adaption factor to the objects emotion factor, typically reducing the effect of future stimulations (e.g. A factor of 90 will reduce stimulus by 90% of current value, whereas a factor of 10 will reduce it by only 10% of current value).

2) Altair AI Engine

This, more in-depth processing, follows one or both of the following:

• An explicit appraisal based on the Discourse chatbot engine which uses an AIML11 derived case based reasoning system, which matches the stimulus (a heard spoken phrase and/or object action defined by ASML) with a suitable response (a spoken reply and/or action defined by AAML)

• A background/implicit/subconscious appraisal based on keyword analysis of the phrase, or the EAD, which again gives an AAML response.

Once complete a final response is sent to the ERM.

3) Explicit Appraisal

For explicit appraisal elements of ASML are used within the context/input fields of an extended AIML implementation (That and Pattern tags in AIML), and AAML elements are used in the response fields (Template tag in AIML).

For instance a case might be (in psuedo-AIML):

<Category>

<That><as:invadingspace/></That>

<Pattern>I don't like you</Pattern>

<Template>That's not nice <aa:sticktongueout/><aa:sad>-10</aa:sad></Template>

</Category>

11 http://www.alicebot.org/TR/2001/WD-aiml/

16161616

4) Implicit Appraisal

Implicit appraisal for objects consists of the same checks against the EAD as for surprise and startle, but without the constraints that drive surprise. Effectively this saves the bot author from coding standard responses to standard objects explicitly (e.g. the bot never likes snakes). For chat, the implicit appraisal is done by checking the chat against a database of words and phrases with an attached emotional value. At its simplest swear words might always make the bot angry or sad, or talk of the sun make it happy. The database expresses the emotional significance in AAML terms for consistent integration.

C. Physiological Changes As detailed above, the appraisal stage will result in one or

more calls to the ERM to influence the emotions of the bot. In the current model we limit the emotions being modelled to the five basic emotions, happy, sad, fear, anger, and disgust [7]

The ERM takes the emotional inputs for each of the five

emotions and uses fuzzy logic to derive the new emotional state. The process employed is to balance the dominant emotion against other emotions. At present the usage of a second dominant emotion is also being investigated to drive a secondary response e.g. highest score might drive facial expression, and second highest might drive posture – this would lead to more complex body language from the avatar.

Note: The ERM is a copy of the same module implemented client side in BotIF. It takes the emotional trigger, applies any relevant fuzzy logic, and then issues an AAML command to generate the appropriate avatar response (usually an emote (e.g. smile), gesture (e.g. hand to mouth) or movement (e.g. move closer/away).

D. Unconscious Reaction Unconscious physiological reactions are not easily

implemented due to the granular nature of the reactions such as elevated blood pressure and galvanic skin responses. However it is feasible that in future projects, subtle physical skin changes such as blushing (embarrassment), pale skin (sadness), and hairs standing on edge due to skin contractions (fear) could be processed away from the physiological change to provide a new tier to emotional visibility where bots in the virtual world can have the ability to show small physiological changes. For instance a new skin or even just an attachment could be used in Second Life to show a blush response, eyes could be changed or adjusted to show iris or blink responses. In some virtual world platforms such as Forterra's Olive, users can manipulate varying levels of bot “homeostasis” functions such as breathing rates and corresponding chest movements. It is intended that AAML could easily be extended to take advantage of such features to provide a broader range of physiological changes under the umbrella of unconscious processing.

Clear application areas of the aforementioned unconscious processing could include medical simulations. Currently bots are deployed in medical training simulations [9] to fulfil the role of a patient whom the user must analyse and treat. One

such scenarios is driven by an implementation of the Medbiquitous Virtual Patient (MVP) model [8] within Second Life [9]. This model includes measures for vital signs such as pulse and breathing rate and AAML could be used to adjust patient vital signs, for instance a trainee doctor with a poor bedside manner may change the AI driven patient heart-rate which is then reflected in the readings being obtained by the pulse oximeter or other device. With the Unconscious Reaction it is feasible that patients could show physical signs of distress that could be used with on-screen data, enhancing the immersion for the participant.

E. Motivation to Act The current Altair system does not support motivation.

Instead the bots are programmed to walk around the sim greeting people who arrive, and being able to answer questions on what services the company offer. Needs and goal based motivations will be introduced in due course – although for greeter bots such motivation should enhance rather than detract (or distract) from their core commercial function. However once motivation is introduced then the emotions module will be able to adjust needs, goals and drives in order to affect motivation.

F. Conscious Realisation As part of the adjustment and storage of emotional and

mood state we also store the reasons for the latest state changes. This means that if a user sees a bot smile they can ask “why are you smiling” and the bot should be able to give a conscious response. In pseudo AIML this would be:

<category>

<pattern>Why are you smiling</pattern>

<template>I'm smiling because %whyhappy%</template>

</category>

The AIML post-processor substitutes the current reason for

happiness for %whyhappy%. If for some reason there isn't a current value then a catch-all value of “I just am” is used.

G. Moods Emotional responses are defined in terms of a very short

duration event, but there is scope to incorporate the emotional response in a longer term mood state. To handle this, fuzzy logic is used to represent the current mood state and this is combined with the current ERM response to vary the mood. To model mood decay, a “half-life” factor is applied over time so that mood abates when there is no significant emotional change.

H. Habituation Whenever a stimulus response is triggered, the emotion

factor is modified by the EAD to reflect habituation, where habituation is defined as the diminishing of the effects of an emotionally significant event [2]. Each robotar has an update cycle which is labelled as a “heartbeat” and is used to update

17171717

the bot’s behaviour and animations when necessary. With emotional bots this heartbeat is used to adjust emotion stimulus factors based on a recovery factor, applying it to the activated entries in the EAD to provide a natural recovery rate, if no subsequent re-activation is made. This will over time, bring each trigger back towards their default values. By setting the value of this recovery factor, recovery can be varied from 1 minute to around 2 hours. During the recovery time the bot will have an appropriately muted response to any new trigger. This initial habituation model will be tested with users in order to develop a more “human like” habituation model, based on their feedback.

VIII. INITIAL TESTING For testing Daden's Halo bot was used. This bot has been

active on the web as a chatbot for over 5 years, and as a Second Life robotar for over a year. The direct connection from BotIF to the Discourse chat engine was replaced by a connection to the Altair AI engine, which in turn was connected to both the Discourse chat engine and the new E-AI emotion module. This module supported the five basic emotions, plus startle and surprise.

A. Set-up To test the bots new behaviours emotionally challenging

situations were created. These scenarios initially involved placing objects in the bot's vicinity. These objects had corresponding entries in the EAD which gave them emotional significance. The first object placed was a snake and this was given an association of fear (as shown in Fig.7 ).

Figure 7. Snake, and bot response.

The second object was a rabbit that had an associated happy emotion. Both entries are shown in table 1 as part of the EAD.

TABLE I. SAMPLE EAD ENTRIES

Stimulus Emotion Value Habituation Recovery

0-100 Multiplicative factor

Multiplicative factor

snake Fear 100 0.95 2

rabbit Happy 50 0.4 1.2

Within Second Life, animal objects were readily available to represent the snake ( a grey animated snake object) and the rabbit (an animated brown rabbit). The bot of course does not recognise the objects as rabbits or snakes, but each object has a related name tag that is read by the bot’s detection system and passed by libsecondlife to the BotIF detection handler when in range.

To test the correct Startle & Surprise operation a snake and

rabbit were first placed in the environment at some distance from the bot before Halo was rezzed. The bot was then rezzed, and then a number of snakes rezzed by the bot. Once bot reactions were complete the snakes were removed and a number of rabbits rezzed.

B. Initial Results When Halo was rezzed she correctly ignored the existing

snake and rabbit – they being beyond the “startle” range. When the first snake was rezzed she gave an extreme fear response – both visibly by gesture and movement (later this will be changed to a “freezing” behaviour that is common with fear), and in the bot's log and debug file. As additional snakes were introduced the fear reaction became less severe – but still obvious – reflecting the habituation profile.

The snakes were then removed and a number of rabbits rezzed. Again the initial response was quite extreme – but of happiness – but the response rapidly faded with each new rabbit – til after the 3rd rabbit the response became extinct.

The tests were repeated over several runs and consistent results obtained.

C. Learnt Emotional Behaviour It was soon evident that the manual creation of the EAD

would cause problems, such as the lack of scalability, the problem of identifying object names, and the lack of a learning approach. Fleming [10] in his VARK model identifies 4 approaches to human learning: visual, auditory, kinesthetic and reading/writing. In Second Life terms these first 3 could be mapped on to: watching others, being told by others, and experiencing (either reactively or proactively).

To see whether such approaches could be used by the robotar to learn emotional behaviour a test was set up around the Second Life damage function. Within Second Life certain areas can be designated as “Not Safe”. Within these areas objects colliding with an avatar (e.g. a bullet, club or explosion) can cause damage to the avatar. Code was added to Altair so that whenever the bot suffered damage then it would

18181818

create a new fear entry in the EAD table for that item, and a level of response proportional to the damage inflicted.

To test this kinesthetic learning a small bomb was created in Second Life. When first placed near Halo the bot ignored the bomb as it had no entry in the EAD. The bomb was then set off and inflicted damage on Halo. Halo's log showed the new EAD entry being created automatically based on the bomb's object name (in this case Bomb 0B). When a new copy of Bomb 0B was rezzed close to Halo she showed the expected fear response.

Having proven the principle of reactive kinesthetic learning, it should be possible to allow Halo to learn other emotional responses by:

• Proactive kinesthetics – e.g. Halo touching each new objecta she sees and seeing what the response is

• Visual learning – watching others interact and gauging their emotional response from their actions and chat

• Auditory learning – listening to others telling it things – e.g. pointing out dangers and delights in a tour of the sim

IX. CONCLUSIONS The E-AI specification was initially aimed at commercial

computer game developers rather than virtual worlds and, as such, was focused on emotions seen in combat style games such as anger and fear (though other emotions were included). However during the project it was apparent that aspects of the Second Life platform (and probably most other virtual worlds) were very different to most games and as such these needed to be addressed, and the E-AI architecture refined. Differences included:

• The AI within a game typically has privileged access to information on object and avatar locations, actions and even intentions/motivations – in Second Life the bot only has access to the same range of information as the human user (i.e. only what it can see and hear in its detection radius).

• The terrain within Second Life can be modified by users on the fly, thus navigation and line-of-sight issues might arise unexpectedly.

• There is no standard naming of objects in Second Life, and no constraints on what objects can be created, so it is not feasible to produce a full prior list of stimulus types. Also the object name may not relate to the object (an object called “snake” could just be a box, or a snake shape called “box”). It is beyond the scope of this project to validate object names (which is a non-trivial problem). The best case scenario is to parse the object name and hope it matches the standard definition in EAD – although the initial work on learned behaviour described above may give an alternative route.

• Prospective bot roles in virtual worlds such as Second Life are more “normal”, such as receptionists, sales people and instructors, rather than one dimensional fighters and beasts. As such a deeper depth of emotion is required to reflect these roles, so bots require a broader range of emotions, including secondary and tertiary emotions, though this is addressed in E-AI.

• The addition of Unconscious Reaction to apply to skin tones in a graphically evolving range of platforms means that blush, eye flickering, and skin contractions(causing hairs to stand on end) can be applied, as such E-AI was updated to now include recommendations in this area.

X. FURTHER DEVELOPMENT The emotional robotar Halo is continuing to evolve, and at

present the EAD is being populated with a range of emotional stimulus and responses through programming and learning. These will provide a stronger test-bed for the in-depth evaluation planned within Second Life involving a range of users reporting back on their interactive experiences. This process will involve an in-depth evaluation of the emotion aspects of users and the bots based on work conducted in evaluating emotion models [1]. Furthermore development is progressing in the area of an emotional chat engine as part of an emotional web support tutor to provide expert knowledge with teaching and emotional responses through text chat.

REFERENCES

[1] S. Slater, R. Moreton, K. Buckley. “Emotional agents as software interfaces,” Workshop at BCS HCI Conference 2008. Emotions and People. Liverpool 2008.

[2] S. Slater, K. Bechkoum, K. Buckley. “Body mind and emotion, an overview of agent implementation in mainstream computer games,” ICAPS 2006. English Lake District. June 2006.

[3] D. Burden. “Deploying embodied AI into virtual worlds,” BCS SGAI Conference 2008.

[4] S. Slater, K. Bechkoum, K. Buckley. “A Foundation of emotion research for games & simulation,” AISB 2007 UK.

[5] K.R. Scherer. “Unconscious processes in emotion: The bulk of the iceberg,” In P. Niedenthal, L. Feldman-Barret & P. Winkielman (Ed), The Unconscious Emotion. NYC 2005.

[6] J. Le Doux. ”The emotional brain,” Orion Books Ltd (Phoenix) 1998.

[7] P. Ekman, Friesen, V. Wallace. “Unmasking the face,” Malor Books 2003. Cambridge MA 2003.

[8] D. Burden, S. Slater. “Serious Games,” IT Now 2008. The British Computer Society.

[9] D. Burden, E. Conradi, L. Woodham, T. Poulton, M. Savin-Baden, S. Kavia. “Creating and assessing a virtual patient player in Second Life,” ReLive 2008, Open University.

[10] N.D. Fleming, and C. Mills. “Not another inventory, rather a catalyst for reflection,“ To Improve the Academy, Vol. 11, 1992., page 137.

19191919