Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
User Interface for the C# Avatar Bots
Clinton Monk
Workflows Team – Avatar-bot Control GUI
Abstract
I created an interface for the C# avatar bots. With this interface, the user can control different
workflow scenarios or set an option to just allow the program to choose different scenarios
randomly. Before this, each C# workflow had to be compiled and “debugged” on the machine
showcasing the workflow. Now any Windows platform with at least .NET 2.0 can install a
simple program that will allow precompiled workflows to be executed. There are also plenty of
additional options and workflows capable of being implemented in the future using this interface
or one like it. In addition to this work, I created a few different scenarios to be used to test the
interface.
1. Problem
The Workflows team, my team, was in charge of designing and implementing various healthcare
scenarios. Different interested users and institution s at the time could not view working
examples of how our implementations of modern technology in the healthcare setting were
effective. Without these examples, these people had nothing to go by and no knowledge of what
we were truly trying to do. Our team was then charged with creating some example workflows to
show to interested groups and hopefully amaze and dazzle them.
Part of the problem lay in not knowing which representation was best to begin with and which
method of demonstrating was the most useful. Different languages were present, including
abstract languages like Lisp and Prolog and more directly related languages like C# and LSL.
Also, some sort of avatars would need to show these workflows in action. Since we want these
scenarios to be easily replicated, bots would be preferred. Two main types of bots were
available: the C# avatar bot based on the OpenMetaverse library and the LSL bot based on a
student-developed code. Since so many options were available, it was up to our team to work to
discover which option contained the most promise and to make it work.
The part of the problem that I worked on was the C# avatar bot. After dividing up the various
tasks to the team members, we began working on our individual parts. Now, I first began
working with the LSL bots, but as we progressed, I realized that the group members working in
that area were alright without my help. I then noticed that the C# bots were having issues, so I
began work there. Realizing how hard it was to implement workflows for these C# bots and how
ridiculous it was to showcase, I decided that a major problem and pitfall was their difficult
implementation. The problem I began to work on was getting the C# bots to work and to create
an easy-to-use user interface for them.
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
2. Objective
The objective of the Workflows team was to create and implement various healthcare scenario
workflows. These workflows would be created in multiple languages and eventually
implemented in the SecondLife world.
The object of my subproject was to design and create a user interface to allow ease of use of the
C# avatar bots. In addition to this, my subproject was to help create some of the multiple
workflows being implemented by my group.
3. Related Work
Two main sources of work were involved in my subproject:

Casey’s UarkBot. Casey had previously done quite a bit of work with the C# bot and we
used his code as a starting point.

OpenMetaverse library. Some awesome guys have made available an open source library
that can be used to access SecondLife from C# programs. Vital to this project.
4. Architecture
4.1 Design
The overall design of the project was to create and simulate healthcare workflows. This design
can be split into two main tasks, each the subdivided into multiple parts:

Healthcare workflow translation to abstract programming languages. Basically, our
group was originally given a rough draft of multiple workflows to try to implement in our
project. These scenarios were very rough, having been compiled together by someone
with a rather nontechnical background. The task to be performed here would then be to
take these scenarios and create workable workflows from them. Two languages were
selected: Lisp and Prolog. Having a proficient Lisp programmer in the group, two group
members translated this information into viable workflows in both languages. From this
work, we hoped that all other implementations could somehow be based off of these
workflows. By finding a way to design a system to have a Lisp/Prolog input, we could
then easily program future workflows in these higher level languages. As of right now,
though, and as far as I know, the other group responsible for a Lisp/Prolog-to-C#
compiler were unable to produce what we were hoping to see.

Healthcare workflow simulation using programmed bots in SecondLife. This aspect
was more concerned with producing visible results that spectators could enjoy. Two
major implementations were available:
o LSL bots. The first bot available to be used was the LSL bot. Nick Farrer, a
senior student at the UofA, had designed a simple bot that could do very simple
features. Seeing the possible use of this bot in our demonstrations, we began
working with Nick to add features to his code. After a rocky start, Nick began
having regular updates that helped implement newer and more complex
workflows. A few of our team members were able to create quite a few
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
workflows using these bots. Some of the handy features are being able to pick up
objects, read RFID tags (code inserts actually) on items, and to be able to
command each other to do specific things. The only real limitation is that these
bots are obviously bots and, as such, may not be very appealing to the average
visitor.
o C# avatar bots. This bot, on the other hand, is exactly the opposite of the LSL
bot. Using part of an open source library, we were able to implement avatars as
bots and issue them code to execute. These bots have a lot of the functionality as
normal avatars, except for the unnatural amount of reverse-engineering needed to
understand the vast library. Unlike the work with the LSL bots, progress with
these avatar bots was slow. That’s because so much extra work and tools were
required. For instance, Visual Studio, a working knowledge of C#, the
OpenMetaverse library, and the UarkBot code were all needed just to edit the
project and test the workflows. And let’s just say each of those were obstacles
themselves. All of this aside, work on these bots progressed nicely after this initial
hurdle was overcome. A couple of our group members, myself included, were
able to program multiple workflows with these bots. And just as the LSL bots had
the downside of not being humanlike, these C# bots have one bad side as well:
lag. Since code is executed on client machines, they must update to the server
constantly, while the LSL bots are executed on the server itself.
The design of my subproject was:

I worked with the C# avatar bots to create multiple workflows and to design a user
interface to easily interact with the bots. Specifically, I used Visual Studio 2008 to
program in C# a Windows Form to control the different avatar bots. Each type of bot was
programmed into a specific class – pharmacist, patient, nurse, etc. From these classes,
bots could be constructed and managed in the main control, or form. Each of these
classes inherited from a general medibot class. Functions used by all classes, such as a
function to output chat or to move, would be inserted into this medibot class and thereby
inherited by all bots. Role-specific actions, such as listening for certain input commands,
were inserted into those specific classes. In this way, only nurse actions were in the nurse
class. This allowed for easy coding and upkeep as the project grew. Now, aside from
these classes, a main form was used to give visual controls to these classes and functions.
This main form consists of a list of the current avatars, an avatar information section that
describes the selected avatar, a set of actions the avatar can perform on command, and a
set of workflows that can be instantiated. A button is also available to log in and out all
bots.
4.2 Testing
Lots of testing was involved in my project. After the initial (and ridiculous) hurdle of
getting the OpenMetaverse library and UarkBot code to compile properly, the testing was pretty
straightforward. I used my home desktop PC and my laptop to concurrently run different
scenarios and make sure everything worked the way it should. I did all of my programming on
my desktop in VS08. I would then compile the code and test it by trying whatever new feature I
had implemented. If something went wrong, such as a bot running away, I would log in on my
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
laptop and place the bot back where it was supposed to be. As work progressed, testing for
extreme cases became more limited and therefore easier to do.
5. Results
Below is a picture of the finished interface:
And below is a screenshot of the Pain workflow in action:
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
6. Conclusions
6.1 Summary
In terms of presenting workflows, the two main choices for bots each have their strengths
and weaknesses. As noted, the C# bots suffer greatly from lag. Even considering the fact that
code can be implemented on a fast client PC, the updates must still be sent and received. This
transmission period is what makes them so inconvenient to use sometimes. The LSL bots make
up for this but, sadly, just are not avatars and cannot become too complex looking (no
transformers) without starting to lag too. With this in mind, we can therefore create future
workflows implementing both using their strengths. The avatar bots can be presentational and
only do simple tasks, such as talking and interacting (nurse, patient, doctor). The LSL bots can
do all of the behind-the-scenes work, like preparing items and supplies, carrying commands, and
travelling the long hallways of the hospital.
6.2 Impact
My individual work should allow for people to showcase workflows using the C# avatar
bots with relative ease. For those skeptical people, without my interface, if you wanted to
showcase an avatar bot workflow, you would need at least Visual Studio 2005 installed on the
machine and you would need to compile the code, meaning you’d need the source too. I believe
my project helps greatly in this respect.
6.3 Future Work
In regards to the C# avatar bots, there is plenty of work left. Right now, the bots cannot
pickup and place any objects. They cannot access their personal inventory. They cannot change
appearance very easily. But I believe they could do all of this with the right amount of time
invested.
In regards to my interface, I believe there is room for a lot of expansion. As the
workflows are completely ironed out, they can be added to the interface. Also, as features are
“unlocked” in the C# bots, they can be implemented in the program too. Considering this is only
what I can already think of, I’m certain there is plenty of work in this area.
References
[1]
openmetaverse.org, http://openmetaverse.org/.
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
Appendix A – Workflows Included
Below is a list of the implemented workflows in my program and the steps involved in each:

Pain
o The patient calls the nurse.
o The nurse asks what’s wrong.
o The patient says he is hurting.
o The nurse goes to the pharmacy to get medicine.
o The nurse asks the pharmacist for medicine.
o The pharmacist gets it and hands it to the nurse.
o The nurse returns to the room and gives it to the patient.
o The patient is relieved and thanks the nurse.
o The nurse asks if there is anything else


If so, continue on.

If not, the nurse returns to her post.
Food
o The patient calls the nurse.
o The nurse asks what’s wrong.
o The patient says he is hungry.
o The nurse goes to get some pudding.
o The nurse returns with pudding.

If banana, the patient is excited.

If chocolate, the patient is alright.
o The nurse asks if there is anything else


If so, continue on.

If not, the nurse returns to her post.
Thirsty
o The patient calls the nurse.
o The nurse asks what’s wrong.
o The patient says he is thirsty.
o The nurse goes to get some water.
o The nurse returns with water.
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
o The nurse asks if there is anything else


If so, continue on.

If not, the nurse returns to her post.
Cold
o The patient calls the nurse.
o The nurse asks what’s wrong.
o The patient says he is cold.
o The nurse goes to get a blanket.
o The nurse takes the blanket to the warmer.
o The nurse returns with the warm blanket.
o The nurse asks if there is anything else

If so, continue on.

If not, the nurse returns to her post.
Appendix B – Notes about the code, notes to the next programmer
States are assigned to each bot to help know what is currently going on. When the patient is cold,
his state is cold. After speaking with the nurse, his state is wait_blanket. Certain messages
specific to this workflow would then include references to these states. If the nurse and patient
are both idle, then the workflow has completed.
Messages are the key method of continuing on in the workflow. To prevent chaos, private
messages (IMs) are used between the avatars to signal different stages of the current workflow.
Lag is an issue no matter what. If too many messages are sent too fast, some may not be
processed. Pausing the thread can help make up for this.
Each expression/animation, once started, needs to be stopped. Otherwise, it gets chaotic. So far, I
haven’t found an effective way to sleep an avatar, so I usually end the animation as soon as it
starts.
Right now, I call the waypoints manually. Nick’s waypoint system works with his robots because
they’re non-physical and phantom.. not the same with avatars, sadly. Until something is done
about it, we’re stuck hardcoding specific paths.
The Auto selection allows for the program to automatically select workflows. This is helpful if
you just want to continually showcase the different scenarios.
Term Project – Final Report
CSCE 4313 Programming Languages – Fall 2008
Comments
What did you learn?
I learned how to work as a team on rather large projects. Trying to meet with and coordinate with
multiple people is hard and this taught me that you need to expect this. Also, I learned quite a lot
of C# while trying to implement these avatar bots.
What did you like about the class?
I enjoy project based classes. Being able to work independently of my classmates but still
towards a common goal was very rewarding.
What didn’t you like about the class?
Unfortunately, project based classes are a double edged sword. For a good amount of time I felt
like we had no direction. This worked out in the end because it made us make decisions for
ourselves. Before knowing this, it was rough.