Second Life

Second Life requires its client, e.g. the SL viewer, to be installed at the user machines. The environment simulated in SL is dynamic and shared between the active users in that instance; therefore, client programs have to rely on the SL simulation servers to get the simulation updates as all the simulations happen at the server side. User inputs through the client UI widgets are sent to the server and processed simulation data are sent to the client viewer to generate the rendered virtual world. Since SL follows distributed client-server architecture with multiple servers for various services such as user management, Instant Messaging, database services and simulation (Sim), and these are connected through the Internet the network latencies can affect the usability. Although this system model allows Linden Labs to maintain its exclusive control, end user experience and system usability can be affected due to network conditions. Linden Labs made its viewer code open source since it has no significant implementation details about the SL server environment.

Second Life is free to access by registering for an account through the user registration portal. Users are authenticated through the Viewer programs and provided with avatars which can be modified to an extent. There were originally two separate systems for different age groups: Second Life is for adults, and Teen Second Life was for users aged between 13 and 17. In December 2010, Teen SL grid was closed and Second Life reduced its minimum age to access the system to 16 years.

Free users do not own virtual land, but they can create content and keep those in their inventory. The 3D environment in SL is based on regions that are virtual islands with 256m x 256m (65,536 m2 _of virtual space). Virtual regions or part of a region can be purchased for a subscribed time period. Although a land area is subscribed by a user, it is treated as a part of the Linden Estate; only Linden Labs can overrule land owner actions. Second Life has one of the largest MUVE virtual economies at present. It operates through the virtual currency known as Linden Dollars ($LD). Economic transactions happen through the Second Life Marketplace [23] and users can convert their real money to $LDs.

36

Marketplace mediates the sales and purchases of land, content objects, and different services in-world, through the transactions based on $LDs.

Content objects in SL, also known as prims, can be any type from the available shapes: cube, cylinder, prism, sphere, torus, tube, and ring. Additionally, three derived versions from these basic shapes, i.e. tetrahedron, hemi-cylinder and hemisphere, are also included. For complex and organic shape creation SL provides the facility to build sculpted prims by uploading a UV map1 _{representing the 3D object} shape. Content objects can be enhanced by associating textures, Notecards and scripts; scripts, which are written using Linden Scripting Language (LSL), determine the behaviour of the objects and how they interact with the users and the environment. Figure 3.1 shows a content building session in SL during the SL event “Learn Teach and Play in 3D Virtual Worlds” [158], organised by the Centre for HCI, City University and sponsored by JISC EMERGE.

Figure 3.1: Content development session in Second Life

Linden Scripting Language

Linden Scripting Language (LSL) is the programming language used in Second Life. LSL programs (scripts) can control the behaviour of in-world objects. LSL has over 300 built in library functions available for users. Most of these functions provide basic forms of API (Application Programming Interface) for interacting with the system IO devices and in-world objects to create dynamic behaviour. Like many other programming languages, LSL allows users to define additional functions, but with a limited scope restricting the control flow to the content object the script is associated with. Second Life does not provide a localised persistent data storage facility. This means the users are not able to store virtual world information outside the Linden servers. Reasonably good documentation about LSL can be found at the LSL Portal [159].

LSL is a state-event driven programming language. These scripts contain variables, function definitions and named states. Each state contains a description of how to react to events, which occur while the program control is within that state. States are defined on mandatory association with the object the script is embedded in. This approach of state based abstraction may be more suitable for simple

1 _{A UV map is a 2D texture representation of a 3D model. The texture contains necessary information to generate}

37

structures such as 3D objects that simulate various states in-world, but many have reported the limited capabilities of LSL due to this approach, among other reasons, which prevented them from implementing advanced programmes for complex requirements. Cox and Crowther have investigated the LSL limitations, and the challenges faced by Second Life users when they use LSL for their in- world scripting needs. According to them, LSL generates considerable lag in response and user experience due to the significant number of listeners used in chat channels [160]. Moreover, the inability to call methods in other scripts has given many developers an unnecessarily difficult situation when they try to develop substantial programs. This was experienced in a number of educational projects we have been engaged in, along with the challenges such as limited script size of 16KB (including script, data, heap, and stack [160]), and comparatively limited support for scripting, testing and debugging. Because of the limited script size, quite often, users must have a large number of scripts in a given object if they need complex behaviour; this is not good programming practice.