MA Reveal: The Educational Sidekick

In relation to the MA Education in Virtual Worlds, last semester saw the completion of the set modules with only the choice of thesis or extended project now to come. They were two very different modules yet not without certain connections; Artificial intelligence, bots and non player characters and The philosophy of education in virtual worlds.

The following notes on the former subject were posted as part of a blog commentary kept during that module, with a number relating to the creation of my own test NPC. They are short academic pieces with references supplied, accompanied by images or short videos.

Emulating Humans
Creating a Non-Player Character
Social Roles of NPCs
Providing Knowledge Lists
Non-Verbal Cues
Is this the wrong focus?
Notes on methods of communication.
Defining the social roles of NPCs.
Directing the user to what is known.
Creating greater character authenticity.
Technical Notes Information on the test chatbot.

As always comments are a welcome addition to any post so do feel free to add your own thoughts or reflections.


Emulating Humans

The in-world chatbot Artificial Iniaes (Iniaes, 2007) demonstrated for me the educational flaw in the majority of chatbots that I have interacted with to date; their apparent lack of purpose other than to be attempts at emulating human conversation.

The AIML based bots that are attempting this can only match input to the patterns contained in their associated AIML documents, and while this may for a short time resemble a normal conversation, the richness of language and the variety of ways we might structure a sentence will inevitably result in misinterpretation of a pattern. This tends to lead to a nonsensical reply, a fall-back to a default response or, as has been evident in many interactions, responses with sexual innuendo or foul-mouthed retorts.

The extensiveness of the latter across various chatbot conversations highlights for me the possibility that many available AIML document sets are just as likely to contain this type of misguided humour as any serious attempt at creating a useful set of AIML categories; an unfortunate consequence of outsourcing for AIML in the search for the perfect conversationalist. Contextual educational categories however will benefit from being more focused.

The attention appears to be on this holy grail of human emulation, sensationalised somewhat by such as the Loebner (2013) Prize. Educational chatbot design could take note of many a video game’s NPCs; it’s not about being human, it’s more akin to personifying a helpful sidekick, supporting the player with specific information for that point in time.

Iniaes (2007) Iniaes. Available from: http://iniaes.org/secondlife/ [Accessed 27 February 2014].

Loebner (2013) Home Page of The Loebner Prize in Artificial Intelligence. Available from: http://www.loebner.net/Prizef/loebner-prize.html [Accessed 5 March 2014].

Back to the Top


Creating a Non-Player Character

My approach to developing in-world agents was to acknowledge the limitations of chatbots as conversationalists and focus on the creation of non-player characters (NPCs). This concentrated on developing agents as support for user engagement with the world (Daviault, 2012, Isbister, 2006) rather than attempting to engage them in authentic conversation. In an educational context this would encompass, for example, the answering of questions on specific knowledge areas.

To enhance the relationship as a personal helper, the development centred on the creation of a NPC that would be assigned to and interact solely with one avatar. A simple character was created and scripted to hover in front of the designated avatar.

In keeping with the personalisation model, conversation between the NPC and the avatar required a communication system that did not flow over to main chat. The NPC’s text was easily personalised by sending it as an instant message. This appears in main chat but is only visible to the recipient. The choices for the user though involved either assigning a channel to each message in the chat input field or using an input textbox.

The text box was chosen as the better option for usability as typing the required channel prior to every message was deemed too easy to overlook. Neither option however provided a record of the user input in main chat resulting in a disjointed feel to the interchange.

This was resolved by having the NPC instant message the user input into chat with the prefix You said:

Daviault, C. (2012) Does game playing experience have an impact on the player-PNPC relationship? Bulletin of Science, Technology & Society [online]. 32 (5), pp. 441-446. [Accessed 1 April 2014].

Isbister, K. (2006) Better Game Characters by Design: A Psychological Approach. San Francisco: Morgan Kaufmann Publishers.

Back to the Top


Social Roles of NPCs

Isbister (2006, p.227) talks about the importance of understanding social roles in the development of NPCs and considers “imbuing an NPC with seeming awareness of role expectations” to be a key aspect in creating “satisfying interactions” with them. As it is the initial perceptions that form a foundation for establishing these roles, affecting ongoing exchanges and future willingness to interact with the NPC, I deemed it important that the opening interaction between the user and the NPC factored in defining its role and doing so in a manner that marked it as agreeable and helpful.

It was noticeable, in interactions with chatbots such as Artificial Iniaes (Iniaes, 2007), that my willingness to engage decreased dramatically as they resorted to disagreeable conversation. As the educational intent of my developmental NPC is to encourage engagement and work with the user to achieve their educational goals, continued engagement is paramount. The dynamics of this relationship is about working together to achieve a common goal but in a manner determined by the user, not the NPC. In Isbister’s taxonomy of role types (Isbister, 2006, pp.227-250) this would align with the least dominant social role; that of minion.

When it is first brought into being the NPC programmatically captures the user’s name, which is then used to personally and politely address them. The NPC then introduces itself, describes its role and gives instruction on how to question it. This defines the future relationship as one of support for the user and their objectives.

Iniaes (2007) Iniaes. Available from: http://iniaes.org/secondlife/ [Accessed 2 April 2014].

Isbister, K. (2006) Better Game Characters by Design: A Psychological Approach. San Francisco: Morgan Kaufmann Publishers.

Back to the Top


Providing Knowledge Lists

As mentioned in Emulating Humans, the richness of language raises problems in terms of the development of sufficient AIML patterns to emulate human conversation for any length of time. At some point the language sent to the chatbot won’t match a pattern, resulting in a fall-back to a recurring default answer. There are also instances where a repetitive response may result from queries addressing different subjects due to the inclusion of wildcards, i.e. _ or *, in the patterns.

In the above example (Worswick, 2014) the AIML category supplying the response “Is this a joke? Why?” would resemble the following:

In developing the AIML categories for the educational assistant NPC, a particular strategy suggests itself to deal with language deficits. As the NPC can only have the knowledge its categories cover, it seemed logical to direct the user to an index of that knowledge when no pattern is matched. To avoid a repetitive response in this instance the direction uses two AIML tags, the random selection tag and the recursive tag (Ringate et al., 2001), to add variety. The following provide a possible 27 different response paragraphs to an unknown pattern through random selection from each list and sequencing of the three categories linked by the tag, yet all responses end in asking the user if they would like to see the knowledge list.

A user’s Yes response to the NPCs list offer is checked against a ‘ThatPattern’ then responds with the list.

Ringate, R., Baer, J., Taylor, A. and Wallace, R. (2001) AIML Reference Manual. Available from: http://www.alicebot.org/documentation/aiml-reference.html [Accessed 10 April 2014].

Worswick, S. (2014) Mitsuku Chatbot. Available from: http://www.mitsuku.com/ [Accessed 30 January 2014].

Back to the Top


Non-Verbal Cues

Further to the knowledge aspects of the NPC and the social role it plays, I also considered in its development how non-verbal cues might be used to create greater character authenticity. Movement is especially important in perceiving a character as being believable and authentic, enabling “engagement and communication through the mechanism of empathy” (Tanenbaum, El-Nasr and Nixon, 2014, p.50). Designing movement that expressed the intent of the NPC, in alignment with its purpose as the agreeable, helpful minion was therefore an important aspect of its development. Though not a human body form, the movement programming of the NPC endeavoured to produce movement behaviour that could be read as aligning with its purpose, such that the user made an empathetic connection.

To achieve authenticity of movement, principles of Laban Movement Analysis (LMA), “a style-neutral framework of movement concepts” (Tanenbaum, El-Nasr and Nixon, 2014, p.178) were taken into consideration and applied as the physics capabilities allowed. In the following video, aspects of the flow between stability and mobility are displayed as the preparatory phrase for action, though in this case not exertion as action, rather, responding to a query as action. The intent however is clear; the NPC is focused on the user and ready to respond.

Gestures also support movement, the actions adding elements of meaning to the intent, but the limbless body form of the NPC made gesture problematic. Blinking provided a means to add gestures (see video below), displaying awareness and clarity of focus on the user.

Tanenbaum, J., El-Nasr, M., and Nixon, M. (2014) Nonverbal Communication in Virtual Worlds: Understanding and Designing Expressive Characters. Pittsburgh: ETC Press.

Back to the Top


Technical Notes

Fred the chatbot is enabled through the Pandorabots platform, a free website that enables the development and deployment of chatbots. The AIML documents that provide his responses are custom made.

To handle queries in Second Life and OpenSim the following url string is sent as an http request where; botID is the published Pandorabots ID; userKey is the key of the person performing the query into main chat; message is the actual chat. These two lines are placed in a listen event where the listened to channel is the main chat; channel 0.

string url = “http://www.pandorabots.com/pandora/talk-xml?botid=” + botID + “&custid=” + (string)userKey + “&input=” + llEscapeURL(message);
llHTTPRequest(url,  params,  “”);

The chatbot response is handled by the following http response event.

http_response(key request_id,  integer status,  list metadata,  string body)
{
        list response = llParseString2List(body, [“<that>“], [“</that>“]);
        llSay(0, llList2String(response, 1));
}

Fred can be interacted with at my workshop in Second Life (see In-World Links in the right hand column). Click on the static Fred and a personalised one will be rezzed ready to interact with you.

Note: This is a test chatbot that I created for research purposes only, during the Artificial intelligence, bots and non-player characters module. He has a very limited knowledge base. I am continuing to work further with him when I have time, especially with aspects of characterisation. Along with blinking, as mentioned above, Fred will now blush if he feels the need to apologise to you.

Back to the Top

About these ads

5 thoughts on “MA Reveal: The Educational Sidekick

  1. Amazing! Simply amazing! As we were designing the virtual world curriculum one of the early ideas based on experience and literature were something akin to “familiars” – companions that would be with the students always in world. They could have taken the shape of say, pets. Their function would have been to provide comfort so they would not feel alone, they could answer basic questions (FAQ), provide navigation if needed and to some degree interaction and plain fun, kind of like Siri. However the complexity made us drop the idea early. This, Fred, is absolutely fantastic and I agree that it could be a pivotal component to effective in-world education, specially for new comers.

    • Thanks Enrique.

      You make a good point too in regards to the comfort function. The co-presence experience, even of a NPC, can be enough to give the perception that the environment is being shared with someone else. This can provide a means to negate that feeling of being alone in the learning space. In my early days in Second Life I created a simpler version of Fred from a movement script I had been given. No complex responses by any means, just simple commands and simple responses (sans Pandorabots), but even in this simpler state I can attest to the sense of companionability that I experienced.

  2. Hi Aaron. I use chatbots as support tools for students in a 3D virtual Careers Atrium (VCA) I am developing at UniSA. The bots currently take the form of: a ‘concierge’ bot to show/take new students to a particular resource section of the 3DVCA; a ‘greet’ bot to greet students as they enter the 3DVCA and recommend use of the concierge bot; and an ‘information’ bot representing one of a set of employer groups to deliver a set response (currently in text box form) to select questions asked by students). In addition to providing information the bots add to the interactivity of the environment. The use of such bots has been favourably received by students who have tested the usability of the Careers Atrium. For most it is seen a friendly face/entity in what is otherwise a lonely, unfamiliar place. The concept of ‘Fred’ takes this one step further by linking (personalising?) the bot to a particular avatar (i.e. student) – great concept. Not sure about the ‘eye’ form though – have you received any user feedback on this? I like Enrique’s “familiar” title.

    • Thanks for the comments Frederick. I’d be very interested in interacting with your chatbots at some stage if that is possible.

      I agree that the eye quite possibly isn’t the ideal ‘look’ (no pun intended); it just has nostalgic connections to my original companion so I kept that appearance while testing it. It has yet to be used with actual students and I would probably consider a less dramatic appearance were I to bring it into play. That said, if the bot were to be a ‘familiar’ it may be more useful to supply a variety of looks for the student to choose from.

      Personally I like bots to be available at my discretion, not theirs, which is why I considered that Fred occupied the NPC type minion. In that vein I created a function to dismiss him when done with; if I type in “Goodbye” he goes. I could envisage adding the capability to call out for his presence in chat fitting that role as well, but not following me around all the time.

  3. Hi Aaron,

    We have been using humanoid NPCs with both chat interaction (implemented through a customised version of the Program O AIML engine that can handle Chinese characters), facial expressions and physical gestures on Chinese Island for some time now. If I may, I would like to offer a couple of observations.

    You mention the issue of the unsuitability of the AIML chat data sets generally available on the Internet for use in educational settings for a number of reasons. Uncivilised responses aside, your observation about the impossibility of anticipating the multitude of questions and variations in the way things can be asked in a general conversation is very true. To be useful for educational purposes, as you point out, clearly the programmed responses have to be relevant to the specific context. As most of my students that interact with our NPCs are beginner level learners of Chinese, to some extent the range of language they have at their command is nicely contained. I deal with non-grammatical input from students using wildcards, and the degree of flexibility can be adjusted reasonably easy (i.e. more or less grammatically correct input required based on particular lesson design needs). Most of what the NPCs can respond to is in line with the content of our textbook (much of which is similar across a large percentage of beginner level textbooks) and the particular scenario in which the task to be completed is embedded. Where a student input is grammatically or semantically incorrect, I have built in two types of responses. The first, using a wildcard which is triggered when nothing the student inputs matches any of the (s) set and prompts a response of “I don’t understand, could you please repeat that”. This negative feedback and request for clarification in second language acquisition (SLA) terms is considered as part of the “negotiation of meaning” process that often occurs in native/expert speaker and learner interactions. The intent of this design is to facilitate “noticing” (also an SLA concept) on the part of the student who, in theory, will look back at what they said to see where the problem lies (the content of which remains accessible in the chat history). In many cases this is what happens (i.e. the student discovers an incorrect character, vocabulary, grammar or syntax) and students then re-input their utterance in corrected form (which sometimes moves the conversation on, at others again results in a non-comprehension response). In some cases, for a variety of reasons, students don’t notice (or can’t “see”) their mistake and the conversation becomes stranded. This often creates a new learning opportunity for the learner where the instructor (or a peer) is then called over to have a look at what went wrong and in the ensuing analysis and discussion the problem is identified, contextualised, and the learner guided to a solution.

    The second type of inbuilt response to erroneous learner input is instructive feedback from the NPC (rather than a simple don’t understand / please repeat). The NPC will repeat the incorrect part of the student input back to the student in highlighted form (usually bracketed) and ask them to try again or will recast (another method under the “negotiation of meaning” model) the student input in the correct form (or using the correct word or character) and then ask the learner to repeat their input using the correct form (word or character). This is achieved by going back through logs of learner interactions with the NPCs to see what kind of mistakes are commonly made across a wide range of learners and then specifically programming these erroneous input into the AIML database with appropriate responses. For the AIML database designer (usually the instructor) this is a tedious process, but one that hopefully bears fruit for the learner should they make a mistake covered in the database. Clearly, if this process is continued over an extended period of time and users you will hopefully get to a point where the majority of common mistakes will be covered.

    Often you come across the situation where a “correct” combination has been input that falls outside the scope of the classroom-based learning content. This kind of situation arises particularly from students who have learned some Chinese outside the classroom. It can be dealt with in the ways described above, but the impact on the student is sometimes quite different from where a student has input incorrect language (due to not having fully grasped everything learned in the classroom environment to that point). When a student knows (or feels) that what they have input is correct because it is something they have used many times in the real world and been understood, it can either undermine their confidence in their existing knowledge or can lead to disillusionment with the whole NPC interaction. I have found that it is critical at this point that the instructor engages with the learner to explain that, if it is indeed the case, what the learner has input is indeed correct but that it was not anticipated and thus not programmed into the AIML database. Going on to say that the term or form used will be added to the database for future use can help the student to feel better about the situation in that they are contributing to the development of the database. Sometimes, however, this kind of situation is an opportunity to point out to the learner that the term or phrase they have used maybe widely used in the world outside the classroom, but that it is in fact an expression or form used in a dialect that is not used commonly in the standard language being learned. In one sense, then, the fact that the database does not cover every possible contingency can provide unexpected learning opportunities.

    There are technical problems with the use of AIML for these kinds of interactive scenarios that can have a negative impact on learner attitude / morale. I am not sure if this is true of all versions of AIML or just the version we are using, but my impression is that the pattern matching gives priority to the smallest unit of input, rather than the largest. This is problematic when an input from a learner could either be a single word or a whole sentence containing that word and where the intended meaning of each is different and where for the sake of reducing lines of code in the database (i.e. where coding in every possible combination containing that single word results in multiple lines of code) a wildcard plus a single character is used for pattern matching. Chinese is possibly a little unique in that the response “yes” to a question is often made by repeating the affirmative form of the verb in the question (often just one character). “No” is made from a combination of the adverb “not” plus the verb in the question (minimum two characters). In this case the AIML seems to prioritise the “yes” response because it is one character, i.e. a smaller semantic unit. It seems the pattern matching program doesn’t recognise the “not+verb” as a single unit of meaning and so outputs the response for the single character affirmative version. This again can cause confusion for learners when they have clearly said “no” in response to something and the response they get back from the NPC relates to a “yes” input.

    Another major technical problem that can have a negative impact on the learner experience (and the credibility of the NPC as an interlocutor in the eyes of the learner) is a breakdown in the server that hosts the AIML database resulting in completely unresponsive NPCs. Usually AIML databases (such as Pandorabots or our own customised AIML) are hosted on servers that are separate from those that host the virtual world in which the NPCs reside. With SL this is complicated by the fact that the NPCs are usually hosted on another server also external to the SL servers (our NPCs are actual avatars rather than objects within the virtual world – I believe this is not a problem in OpenSim). The inter-server interactions become quite complex, with SL servers conveying data to the NPC server which then conveys linguistic input data to the AIML server, and vice versa. We have experienced a number of occasions where one server has gone down or is experiencing problems thus effectively putting the NPCs (and their chat function) out of action. As a result of these experiences I have to say that I am now strongly leaning towards having NPCs and the dialogue database all being hosted on the same server as the virtual worlds environment. For me this means using object-based NPCs (made from mesh and animated via puppeteering) and a chat engine developed using LSL, all of which is hosted in the same place as the OpenSim or SL region they are located in. For the NPCs facial expressions, gesturing and movement are all still possible, albeit less fluid and “natural” than avatar-based NPCs. The big challenge is developing and LSL-based chat engine that has the flexibility and scalability of AIML. This is something we are currently working on and we hope to have a working version of an LSL-based chat engine ready very soon.

    I guess we see the role of the NPCs in our scenarios as somewhat different from what you described. Rather than being “sidekicks” that accompany the learner in the virtual environment (which is something that I have also really wanted to develop for a long time now), the NPCs play a couple of different vital roles. They are “gatekeepers” for the tasks that the learners are expected to complete in the various scenarios. While we do provide quite detailed instruction about the different stages of each task to be completed, the NPCs provide key information about what to do next “in character” as part of the “natural” flow of conversation with learners (sometimes this information is given very directly, other times the students have to work hard to get the information by asking questions). Often they give permission to continue on to the next stage through, for example, accepting payment and giving out information or objects that enable learners to go on to the next stage. They are also interlocutors that provide the learner with the opportunity to put to use the language they learn in the classroom and that provide responses that are in character and relevant to the scenario but that are not entirely predictable by the learners.They also play the role of key characters in the scenario that convey information about the scenario (and the real life situation being simulated) through their clothing, their location, their gestures, their language, etc. They also play an instructive role, albeit in a relatively limited way, which includes modelling language and providing feedback on specific learner input. Our NPCs are meant to emulate real humans, and there are times when the students react to them like they were humans (or at least controlled by a human – students will often say “he” did this, “she” did that), but this can also sometimes intensify the feeling of frustration when a breakdown occurs. In a practical sense too they also play a very practical role in that they are able to interact with multiple learners simultaneously (something a human interlocutor would struggle to do) enabling learners to work through the task at their own pace unimpeded by other learners, but equally able to collaborate with other learners. They never get tired, rarely go on strike (except when their server crashes) and are always available when you need them, unlike human interlocutors.

    Sorry for such a long posting. I love what you have written, the depth of thought you have given to the topic and the insights you have shared. I hope you will continue to share your insights with us in the future.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s