As a content creator I have focused on interactivity: the world is so much more engaging if one can interact with it rather than just look at it. My experience of Second Life is that most of the content has no or limited interactivity. The most recent data at hand regarding the percentage of users who create content is Ondrejka’s¹ paper which states that 42% of Second Life users have created objects, that 44% have sold an object and 77% have bought an object. My experience clearly indicates that many more residents can build than can script. I estimate that fewer than 10% of residents can script, probably much fewer.

One key thing that has allowed me to create interesting content is the method of creating several simple objects with simple behaviours and combining them together to create something that exhibits apparent complexity. The following section examines some of my creations, starting with simple doors and moving on to objects of increasingly greater complexity.

Doors

Doors are one of the simplest and most common types of interactive object in Second Life. Typically doors are a single prim with a script on it which will rotate the door around a specified axis or move it in a specified direction (in the case of a sliding door) when it is touched. A resident touches an object by clicking it with the mouse. A simple example of an LSL sliding door script follows. Lines beginning with “//” are comments, describing what the script does.

default
{
    touch_start(integer n)
    {
        // In the default state, when touched, move
        // the door 1.0 metre along its X axis, and
        // transition to the "open" state:
        llSetPos(llGetPos() + <1.0, 0.0, 0.0>);
        state open;
    }
}

state open
{
    touch_start(integer n)
    {
        // In the open state, when touched, move
        // the door 1.0 metre in the opposite direction
        // along its X axis, and transition to the
        // default state:
        llSetPos(llGetPos() - <1.0, 0.0, 0.0>);
        state default;
    }
}

As can be seen from this example, it requires only one line of code to open the door and another to close it. The remaining code defines two states, and declares that when the door is in either state (default or open) the script will execute a particular action when touched. Complexity can be added to, for example, make the door open more smoothly, afford access control, control the amount of time it takes for the door to open or how long it remains open.

This simple type of interaction lends itself to a variety of applications other than doors. An example of a slightly more complex application of this same basic action is The Big Red Button. I created a large, round, red button object, with a script which, when touched, first makes the button glow to indicate activation, next moves the button prim down into its base to indicate the button being depressed, then sends a message (a text string) to the door (a separate object) to tell it to open. This is the equivalent of touching the door. When the button is touched again, or after a predetermined delay, the script turns off the glow, raises the button and sends another text string to the door telling it to close. These basic principles can be extended to afford the development of a complete inworld home automation system.

Although this kind of implementation seems quite simple, it is beyond the skills of most residents of Second Life to implement from scratch. Even if they are not able to manage complete creation of this kind of interaction, users who have no scripting skills can add pre-made scripts to objects by dragging them from their inventory and dropping them into objects. There is a market in pre-made scripts, with over four thousand scripts being offered for sale on the Second Life Marketplace as at the 1^st of February 2011. I have a business in the world and my partner and I make a range of items, including many scripts which we offer for sale. We receive a great deal of feedback from our customers that they value these scripts as we include detailed, easy to understand instructions that enable even very inexperienced users to understand and customise these scripts. My experience is that most scripts offered for sale in Second Life provide no explanation of any kind of how they work, or are sold with the permissions set so that the user cannot even view the script, let along edit it. Sales of scripts that users cannot view are obviously a serious impediment to residents who wish to learn how scripts work. Because of this and because of their desire to resell or freely share their creations users prefer to purchase full permission scripts. There is obviously a tension between residents who seek to educate themselves and those who want to include scripts in objects for distribution on the one hand, and the mindset of those scripters who feel they have to prevent users from viewing their scripts in order to ensure sales on the other. My experience, on the contrary, is that my business continues to sell a great many full permission scripts year after year. It is however also important to bear in mind that a great many users have no plans to sell the items they make, but rather enjoy giving them away freely.

New Kingdom Chariot With Horses

Figure 9 shows a New Kingdom chariot pulled by two horses that my partner and I constructed. The chariot comes in three pieces; the chariot, the right horse and the left horse, which includes the harness. The chariot is a vehicle and the horses and harness ordinary grouped objects. Making the chariot a vehicle means that it is a physical object, that is, an object that interacts with the inworld physics system. By default objects do not have this interaction. It must be discreetly set. Additionally a vehicle contains a number of automated behaviours, among them are; deflection of linear and angular velocity to preferred axis of motion, asymmetric angular and linear friction, hovering over terrain or water or at a global height, banking on turns, linear and angular motor for push and turning². A vehicle can be comprised of no more than 32 prims³, which is quite limiting when one wants to make a complex object that has many parts that move in many directions, like a horse’s limbs. In order to activate a vehicle one sits on it, at which time the arrow keys control the motion of the vehicle.

In the case of the chariot, one sits on the chariot and then wears the horses. To wear an object means to attach it to a point on one’s avatar’s body. Doing this allows one to work around the 32 prim limit for vehicles. The chariot is comprised of 24 prims, the right horse 13 prims (head, ears [the two ears being one object], neck, body, an upper and a lower half for each leg and a tail) while the left horse, including the harness, is 35 prims. Once one sits on the chariot, which in this case arranges one in a standing position, the chariot offers the avatar the horses, which are contained inside the chariot. The horses are then added to the resident’s inventory, from where they are worn. Similarity to the way the sit position is specified the position in which the horses are worn is also specified by the creator. Once the horses have been worn one can use the arrow keys to steer the chariot around. The page up and page down keys will shift the chariot up or down gears respectively, thus varying speed and the ability to move over sloped surfaces.

The next important consideration is to animate the horses so they look as if they are walking. The need to do this is why the horses have to be comprised of so many objects. In LSL it is possible to have a script on one prim send a message to all of the other prims in a linked set of which it is a part. Scripts on those other prims receive the message and can cause actions to occur in repose. In the case of the horse there is a horse brain script, which sends messages to all the other scripts which are on each of the parts of the horse’s body which need to move. The brain script sends a message every 0.3 seconds to the other parts of the horse and when they receive it a walking state is entered and they each move a predetermined distance or direction in either the x,y or z axes. This same functionality is employed in order to have the chariot tell its wheels to rotate either forwards or backwards once movement commences.

The chariot also needs to communicate with the horses in order to tell them to move forwards or backwards or to stop. Because the chariot is not part of the same linked set as the horses a different mechanism must be used to allow them to communicate. Second Life includes the facility for about 4 billion communication channels. Among these are the local chat channel and a debug channel for error messages. Each channel has a number to identify it, with local being designated 0 and the debug channel being 2147483647. A resident can select a channel in their script by specifying any other number than these two. If an avatar says something and doesn’t specify a channel the message will go to the local channel. In a script however one must specify a number for the channel. For example the chariot sends messages to the horses on channel number 41138. The scripts in the horse’s body parts tell them to listen on this channel.

As can be imagined from the description of this process, creating such animations is an incredibly time consuming activity. I estimate we spent about 50 hours in building, coding and testing the chariot. First all the objects have to be built, which includes research into, in this case, the exact form a New Kingdom chariot took. I built the chariot and its harness from prims from scratch. The horses were custom built by another resident who specialises in making animals and my partner and I worked on the scripts together. This is a typical method for constructing complex objects in Second Life. Many of the individual components are complex in their own right and require a well developed skill set to produce them. The horses were made of sculpted prims, a process which requires an external 3D modelling program. The scripts are among the most complex found in the world, my partner is a professional software engineer, and I a multimedia developer. My partner and I have undertaken several large and complex builds in the world and working this way has proven to be the most efficient way to obtain the best result in the least time.

1. Ondrejka, C., (2004), “Escaping the Gilded Cage: User Created Content and Building the Metaverse”, New York Law School Law Review, Vol. 49, No. 1. ↩︎
2. Second Life Wiki, Linden Vehicle Tutorial, http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial, Accessed 08/02/2014. ↩︎
3. Second Life Wiki, Limits, http://wiki.secondlife.com/wiki/Limits, Accessed 08/02/2014. ↩︎