Half Day Challenge: Melee

Got distracted there for a while so things ran on for more than half a day. Still, this is the last update.

Just to round things out I added in melee. Very simply when a unit activates it scans for adjacent enemy units and then distributes its melee attack across them. By rights it should also lock movement, but that's for another time.

The end result is a skeleton for a more advanced system. At the moment there are no real rules, but I've tried to use a modular system that would make it easier to expand. The visuals are also more at the abstract end of the spectrum, but they could be replaced with small figures or, maybe in an OpenSim megaregion, full-size models.

Half Day Challenge: Ranged

The video shows the basic movement and ranged combat.

This first system is as basic as they come. The player selects a target and the unit uses the llSensor function to see if it is within range. If it is then it informs the target that it has taken damage.

Of course usually there would be a random check made based on the distance to target and units skill, and possibly random damage as well.

Half Day Challenge: Movement

A few overheads in setting up, but I now have a HUD that controls orientation and movement. I'm using the llDetectedUV function for both.

For the rotation this touch coordinate needs to be converted to an angle, which you can do using the llAtan2 function - just remember to subtract 0.5 from both x and y to move the origin to the centre.

vector touchPoint = llDetectedTouchUV(0);

float angle = llAtan2(touchPoint.y - 0.5, touchPoint.x - 0.5);

The angle will need adjusting so that clockwise is positive 0-180, and anticlockwise is negative. The OpenSim version that I'm using (0.7.02) returns inconsistent results for the four 90 degree quarters, so it might take some trial and error depending on what system you're using.

For movement, I'm just passing on the x component. Since this is just a number between 0 and 1 I'll use it to scale the movement. While on the subject, moving objects "forwards" is very easy using the built-in functions:

// Get the current rotation

rotation myRot = llGetRot();

// Get the vector that is pointing "forwards"

vector fwd = llRot2Fwd(myRot);

// Get the current position

vector myPos = llGetPos();

// Move forward a distance based on variables maxSpeed and movementScale

myPos = myPos + (fwd * maxSpeed * movementScale);

Just remember that an objects forward direction is along its positive x axis.

Time for lunch.

Half Day Game Development Challenge

I've found some free time over the Christmas break, so I thought that I'd devote half a day to working on a game project - it is the title of this blog after-all.

SL-based platforms aren't a good choice for real-time games. Basically, unless you're running a dedicated sim in SL with very little on it, then lag is going to be a major problem. As much as I love OpenSim, its performance would be even worse.

I've always thought that SL is a better platform for turn-based games. If you think about real-life, apart from sports, most games are turn-based, from hopscotch, to Monopoly, to Warhammer, to poker, to spin-the-bottle. Although this is hardly an epiphany, since most of the games that I've come across in SL were turn-based.

Anyway, since New World Notes reported that SL's new CEO had worked on some Open Source miniature wargame rules, that seemed like a perfect fit. I'll update on progress.

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.