2 days of presentations

2 days, 2 presentations - both on Second Life. The first a joint presentation in an arts-focused seminar, based on the virtual theatre work, the second a presentation to built environment educators and trainers on the University's virtual quarry.

Common to both was the advice that anyone looking into using immersive simulations in their teaching, should make OpenSim their first choice. I'd guess that it's common advice circulating through the educational sector. At a time when funding is being cut to the point that jobs are being lost, there's no way of justifying the cost of 'trying it out'.

A model is starting to form in my mind where institutions jointly hire some hosted OpenSim land, and collaborate to produce a learning activity. And then when it's complete each institution takes a copy to use on their own local servers, run when required. We're entering times where the efficient use of resources is paramount.

Results of OpenSim/SL Exercise

Last week we ran the SL/OpenSim activity for directing actors. The overall aim was for students to work in groups to plan out the stage direction for a piece of dialogue from Hamlet that only involved Hamlet and Ophelia, and then present their plan to the rest of the class. Virtual representations of the Globe theatre were used both as planning tools and the source of screenshots to use in their presentations.

There were 4 groups. At any one time only 1 group was in Second Life, and 1 was in OpenSim. They took it in turns, so ultimately 2 groups used OpenSim and 2 used Second Life.

The OpenSim setup is shown in the diagram below (the Second Life setup was identical, except that they connected to the Linden server instead of another PC in the room). Each group had 3 PCs, with two group members controlling the actors, and the remaining group members huddled around the 'director' PC. ((No it isn't the official Imprudence logo, but it's one of the variations that I prefer))

So how did it go? Put simply, very well. From the student experience point of view SL and OpenSim use was near-identical - one student did comment on OpenSim's tendency to flick the avatar's feet up to waist height occasionally. There were no crashes in either setup, and nothing noticeably weird happened. However a few general points did arise:

Getting to grips with SL

An issue that often arises in virtual world activities is the overhead in learners getting to grips with the technology. If anything we experienced the opposite effect. We bypassed all of the account creation/teleportation/inventory issues by providing ready-made avatars en-situ. Actors were on stage suitably dressed and the director was in the 'pit'. Actor controls were just the arrow keys to move around; the director controls were camera adjustment and screenshot taking. This wasn't enough for the students as they experimented with flying, text chat, and using gestures to act out parts of the dialogue.

It should be said that these were English Literature students, with a voiced aversion to 'techie' things. Some of the challenges experienced in introducing SL activities might be caused by exposure to too much early on. The group structure also provided peer support and allowed 'back-seat drivers'.

Phychomotor vs Affective learning

The activity was very successful in terms of students being able to use the technology as an assistance, rather than hindrance, in planning their stage direction. However, it seemed to be a less successful activity in terms of leading to an affective change in their understanding of Virtual World (VW) uses. There seemed to be a lack of imagination or extrapolation as to how VWs might be used in other areas.

This is probably a symptom of how the activity was designed. Removing distractions limited their view of the bigger picture. It's something that will be addressed in any future activities, but I'll wait to see what appears in the students' reflective journals before passing judgement.

AIMLBot and Open Metaverse

To remove any hard work in creating a chat bot using Open Metaverse, I performed a search for C# AIML parsers. Top of the list was AIMLBot (http://aimlbot.sourceforge.net/), and after a bit of poking around they seem to work well together.


There was some head scratching because the chat example on the Open Metaverse page (http://lib.openmetaverse.org/wiki/Respond_to_inworld_chat) seems to be out of date - the LL prefix from LLUUID and LLVector3 seem to have been dropped. The AIMLBot also doesn't come with the xml and aiml files needed, but I just took those from Radegast.

As it stands the chat call back is fired whenever anyone starts typing nearby, and when it hears itself. My slap-dash solution is included below:

static void Self_OnChat(string message, ChatAudibleLevel audible, 
 ChatType type, ChatSourceType sourceType, string fromName, 
 UUID id, UUID ownerid, Vector3 position)
{
  if (message != "")
  {
      if (fromName != "Test Bot")
      {
          //process chat here
          AIMLbot.Request request = new AIMLbot.Request(message, 
            myUser, myBot);
          AIMLbot.Result reply = myBot.Chat(request);

          Client.Self.Chat(reply.Output, 0, ChatType.Normal);
          Console.WriteLine(reply.Output);
      }
  }
}

That's the main component of the chat bot, so you can see that it is very easy to implement.

MCQs in SL

Shown in the video are various options for showing multiple choice questions (MCQs) in SL. The fundamental criteria was that the questions needed to be attached to an object in-world, and so there were 3 main options:

1. Dialogs: MCQ presented through a series of dialogs. Only a certain amount of text can fit on a dialog button, and so longer options need an ABC-style system.
2. HUD: Very similar to the dialogs, but allows for 'bigger buttons' to display options.
3. Website: Displays a website using the in-built browser. In this case the website was made using software called Twine, but any html page would work (including javascript).

The dialog and HUD are roughly equivalent; with the HUD possibly just having the edge since its appearance can be customised, and it doesn't have the button size restrictions. The website option has many advantages, including support for images and larger passages of text, but requires a server somewhere to host the pages, and extra effort in authoring them.

In the video the Dialog questions load slightly faster because they are hard-coded, while the HUD is reading from a notecard. The notecard is the better option because it is easier to produce questions for. The system that I'm using requires lines to start with special characters, as shown below:

?Question
*Incorrect option
*Correct option<
*Incorrect option
+Positive feedback
-Negative feedback
#

I think that this is a fairly straight-forward, human-readable format, so putting together quizes shouldn't be too difficult.

I want to briefly mention Twine, which is a fantastic tool for creating branching scenarios. It was used in the website example to create a linear quiz, but it can be used in much more creative ways. Full details can be found here: http://gimcrackd.com/etc/src/

Second Life Games Directory Update

15 more games added; many more still waiting.

http://thoughtfulmonkey.com/slgameslist/

Toy Interface

I added the video to YouTube, but forget to comment on it here. Basically it's very easy to make all sorts of interesting user input devices if you can get hold of a keyboard encoder. A keyboard is in essence a lot of buttons connected to some electronics that communicates to the computer. A keyboard encoder is just a stripped down keyboard, which allows you to add your own buttons.

In the example below I took a childrens toy and wired it up to control the avatar in second life. For example the accelerator pedal is wired up so that when you press it, the encoder tells the computer that the up arrow key was pressed. Very easy.

As a rule of thumb, if the toy makes a noise when you press/turn/squeeze/shake/whatever, then you can use that as an input. Just find the two wires that go to that part, and connect them to your keyboard encoder instead.

Using the Meerkat viewer

Shown above is the Cannons and Castles game, ported from SL to a local OpenSim grid using the new Meerkat viewer (discussed in several places). It's fairly fast and pain free, but doesn't carry over scripts - and may never be able to.

It looks like a great option for people to backup work, create locally and then upload to SL, or to flee the sinking ship (2 years of sinking and still no change in the water line).

Interestingly the data is saved to an xml format, which is likely to lead to an explosion in tools for procedurally generating content, file conversion and import/export plugins. It looks to be a much more elegant solution than current systems.

llDetectedTouchUV function

I'm not sure when it was added, but the ability to determine where the user clicked on an object's surface is very useful. To try it out I threw together two examples, shown in the video below.



Subbuteo:
The HUD calculates the distance and angle from centre of the point clicked, and applies an equivalent force to the Subbuteo player. ((I wasn't impressed by Ronaldo's finishing))

Star Fleet Command III turning:
You can click on the ring surrounding the ship to set a heading.

SL Games List

There doesn't seem to be one around at the moment, so I've made one myself:

http://thoughtfulmonkey.com/slgameslist

This will be a steadily expanding list of the games available within Second Life. They won't be reviewed; just briefly described and linked to.

Pocket Battlers - Generation 1 prototypes

At the moment I'm just getting a few ideas out of my head, and into working prototypes. One of these is Pocket Battlers, in which you control a small 'Battler' (as a sub-avatar?) that can move around and launch various attacks. A major feature is that these Battlers can be very different, for example in the first generation with be a tank, a pirate ship and a faery; all with appropriate movement and unique attacks.

The second major feature is the power bar, through which attacks are activated. Power gradually accumulates over time, and each attack requires a certain amount of power before it can be used. When an attack is used then a portion of the power is used up. You can see it in action at the end of the video below (there's no sound so don't go fiddling with your volume control).



They still need a bit of dressing up, but after a few small tweaks they'll be at the stage where they can be fought against each other (I just need to add in area-effect damage).

Credits: The particle systems used for the faery are based on free examples available at 'The Particle Lab' in SL, and the faery's wings are by Jane Mc Carthy.

Steamboy rocket

If you've seen the excellent animation Steamboy, then you'll no doubt remember the one-man rocket that he mashes together in a couple of seconds (as shown on the poster).

The video shows a Second Life version that I'm working on. It's a little bigger than Ray's, and still can't achieve lift yet, but if the rivets hold then it should be airborne soon.

There are quite a lot of prims involved in the pipe-work, so a large part of it is going to have to be an attachment. And don't get me started on the pose - the only way I can stop the avatar bending freely at the waist is to use a looping wiggle. Any alternative suggestions are welcome.

Cannons and Castles

Version 1 of the game is all but complete, and provided an excuse for my first Machinima production. As expected more time was spent learning the tools than making creative decisions, but it turned out well.

In the game two players compete to destroy each other's castles. It's basically an extended version of rock-paper-scissors. You pick one of three of your opponent's towers to attack with your cannon, and one of three of your own towers to defend with your wall. The towers add a level of strategy since each one can only be hit twice, and you need 4 hits in total to win.

IM me in-world to try it out.