400390107. Segunda Vida: La perspectiva de un Programador

Dana es una científica que trabaja en una división de BBN Technologies con experiencia en los campos de computación colaboradora y de igual a igual, plataformas de agentes de software y entornos de asistencia. La identidad de Dana en Segunda Vida es la Expedición ElectricSheep (OvejaEléctrica). Raymond es un ingeniero de software que trabaja en BBT Technologies en donde ha diseñado y desarrollado una serie de aplicaciones web y otros sistemas distribuidos. Se puede contactar con él en: ray.budd@gmail.com. El último libro de Dana y Raymond es “Professional Rich Internet Applications: AJAX and Beyond” (Wrox, 2007).

Habiendo llegado a la velocidad en los conceptos de Web 2.0 tipo AJAX, Ruby on Rails, y Turbogears, muchos desarrolladores han empezado a pensar en el mundo más allá de Web 2.0, mediante la pregunta: “Si hay una ‘Web 3.0’ ¿qué es, y que aspecto tiene?” Una posibilidad es una Web de próxima generación representada como un Rico e Inmersivo Entorno (RIE) que, en vez de aparecer ante los usuarios como una forma en dos dimensiones en un navegador, los traslada a un mundo tridimensional lleno de sitios que ver, avenidas para pasear, gente con la que relacionarse, objetos y entornos con los que jugar, cosas que comprar y servicios a los que acceder.

Las aplicaciones arraigadas en esos entornos requieren de un estilo totalmente diferente de manipulación por parte de los usuarios y de interacción con dichos usuarios. En resumen, necesitamos reconsiderar lo que significa el concepto de “interfaz” y cómo involucrar a los usuarios con tu trabajo.

En el presente artículo, vamos a examinar lo que implica el desarrollo para Segunda Vida (www.secondlife.com), un RIE emergente desarrollado por Linden Lab (www.lindenlab.com). Segunda Vida ha conseguido tanto grandes mentes como una importante cantidad de ingresos por relaciones comerciales auténticas para los participantes y creadores de valor virtual.

¿Qué resulta tan atrayente de Segunda Vida y otros mundos virtuales (no de juegos) tan emergentes? En una entrevista realizada en 2006, El Director ejecutivo de Linden Lab, Philip Rosedale explica que cuando entran en Segunda Vida, los alter-ego digitales de la gente (a los que se conoce como “avatares”) pueden moverse y hacer todo lo que hacen en el mundo físico, pero sin molestias tipo leyes de física. “Cuando estamos en Amazon.com (con la tecnología web actual), estamos realmente allí junto a otras 10.000 personas que concurren contigo, pero no puedes verlos o hablar con ellos”, comentaba Rosedale. “En Segunda Vida, todo lo que experimenta uno es experimentado de forma inherente con los otros.”

Pensemos en lo que esto implicaría en un sitio de carácter social. En lugar de enviar entradas y respuestas en slashdot.org o digg.com y leerlas después desde una página web o una alimentación RSS, imaginemos que conversamos en tiempo real con los compañeros reales sobre historias que surgen de las fuentes reales de noticias como Reuters o CNet. Imaginemos que abrimos un sitio en primera línea para nuestra próxima idea brillante y que lo tenemos literalmente en primera línea, desde donde podemos, en tiempo real, interactuar con nuestra base de usuarios y clientes potenciales.

Imaginemos un mundo en el que podríamos realizar múltiples tareas atendiendo primero a las actividades personales desde “casa”, girando nuestra atención al “trabajo”, descansar después para “comer” en una empresa RPG o ir a una playa virtual en mitad del día.

Esa es la promesa que sugiere Segunda Vida. Pero hay otras razones varias por las que debería estar en nuestro radar de desarrolladores:
– Se realizan transacciones comerciales en Segunda Vida. Tiene una economía real alimentada por una moneda real. Aunque la mayoría de los bienes y servicios que se encuentran en Segunda Vida son virtuales, el dinero es real, y la propiedad intelectual que creamos es nuestra. De esta manera, la programación que realizamos en este mundo se puede convertir en ingresos reales. Los residentes gastaron más de 200 millones de dólares en este mundo virtual durante 2006.
– Cada uno de los objetos que hay en Segunda Vida está allí porque lo ha creado un desarrollador de software. En la actualidad, la encarnación SL del “metaverso” es la frontera abierta, el salvaje oeste. No hay grandes jugadores que controlen el paisaje; con dominar el Lenguaje de Scripting Linden, estamos en una posición equivalente a la de cualquier otro desarrollador del mundo.
– Los clientes potenciales son fieles al entorno y a la experiencia. Se estima que los «residentes” de este segundo mundo actualmente pasan 40 horas al mes dentro de ese mundo, algo más de un 10% del tiempo que pasa el americano medio ante el televisor al mes. Consideremos el impacto positivo que representa para nuestra empresa ese nivel de exposición ante clientes potenciales.
– Segunda Vida es una experiencia inherentemente social, más que un entorno para jugar. Se ha calculado que algo menos del 50% de los residentes en SL son mujeres; lo que sobrepasa con mucho la inmersión femenina en entornos de juego. Cualquier empresa basada en web que es capaz de atraer a ambos géneros contiene una importante promesa.
– Nuestras creaciones son potencialmente escalables de forma infinita. Podemos crear gafas de sol que cambian con la sombra o dirigibles, y después de vender la primera copia seguimos teniendo un número infinito de artículos.

((Se ha calculado que algo menos del 50% de los residentes en SL son mujeres; lo que sobrepasa con mucho la inmersión femenina en entornos de juego))

Segunda Vida: El punto de vista del Programador

El primer atractivo para los desarrolladores de software al usar una plataforma como Segunda Vida, es la posibilidad de crear objetos que tienen un dinamismo realmente creíble, incluso si los comparamos con AJAX y otras aplicaciones basadas en navegadores. Virtualmente cada uno de los objetos que encontramos en SL, desde balones de playa a centros comerciales, ha sido creado por un desarrollador o un equipo.

Una breve (e incompleta) descripción de SL es que es un enorme simulador que ejecuta un número potencialmente enorme de máquinas de estados finitos (FSM, por sus siglas en inglés). El entorno del scripting que controla la ejecución de cada uno de las FSM – las nuestras y las de otros – es un lenguaje tipo C denominado “Linden Scripting Language” (LSL).

Elementos esenciales en Segunda Vida

Para cualquiera que busque realizar algún tipo de desarrollo serio en SL, es necesario convertirse en residente, representado por su propio avatar, y pasar tiempo en SL. En un sentido real, podemos pensar que el tiempo pasado en SL es como participar en un entorno de operaciones cambiante y en vivo para el que creamos artefactos, a menudo soportados por nuestro código.

Cuanto más tiempo pasemos participando en SL mejor entenderemos las capacidades y limitaciones de las maquinas de simulación y de representación en SL. Un concepto interesante para los desarrolladores es que se vive tanto dentro de una aplicación como de un Entorno de Desarrollo Integrado (IDE, por sus siglas en inglés). Cuando uno se encuentra con ganas de codificar, aprieta el botón “Build” en la parte inferior de la pantalla e invoca el IDE.

Primero tenemos que descargar el cliente SL para nuestra plataforma. Hay clientes para Windows, SO X de Mac y un Linux beta. Después de instalarlo, nos creamos una identidad (un avatar). Cada nuevo avatar hereda una colección de objetos, que da Linden Lab. Todo lo demás que nos pertenezca ha de ser comprado o creado por nosotros o por otro residente.

Cuando creamos objetos, podemos tenerlos en nuestro inventario, que se puede expandir infinitamente y puede ampliarse para contener toda nuestra colección de ropa virtual (además de un armario de roble antiguo para guardarlo). Por supuesto, conforme nuestro almacén virtual se va ampliando, la recogida de base de datos que se necesita para habitarlo tarda más cada vez que nos conectamos a SL. Hay técnicas para comprimir las posesiones, pero lo mejor que podemos hacer es comprar tierra virtual en ese mundo.

Si compramos y mantenemos tierra virtual en SL, podemos colocar en ella lo que queramos y ahí seguirá. Esta regla se aplica a los artículos que compramos o que creamos. Así, por ejemplo, aunque nuestra biblioteca de objetos pueda contener elementos interesantes y aunque podamos crear artefactos, necesitamos adquirir tierras para darlos una presencia permanente. Así es como miles de residentes han creado sitios comerciales que producen ingresos vendiendo moda, automóviles y otros artefactos virtuales.

((Como las cajas de arena se limpian dos veces al día, es importante asegurarse de que copiamos nuestras creaciones en nuestro inventario de forma periódica))

Tras introducirnos en ese mundo, se recomienda tele-transportarse a una de las zonas de cajas de arena para construir y comprobar los objetos que hemos creado en una caja de arena. Y después los copiamos a nuestro inventario.

Como las cajas de arena se limpian dos veces al día, es importante asegurarse de que copiamos nuestras creaciones en nuestro inventario de forma periódica (“guarda pronto, guarda con frecuencia”).

Sólo podemos crear objetos con las herramientas de construcción de ese mundo (hay persistentes rumores de que con el tiempo se podrá importar modelos externos), pero conviene que creemos animaciones de forma externa con Avimator (avimator.com), y después los importemos a ese mundo. Podemos usar el editor de coloreado de sintaxis en el compilador de objetos IDE, o usar un editor de texto externo (hay plug-ins para unos cuantos bastante conocidos).

El Modelo de Objeto SL

El mundo virtual que representa Segunda Vida consiste en un banco de servidores, cada uno de los cuales es responsable de gestionar objetos, terrenos y avatares y de garantizar que los clientes conectados al servidor se actualizan de forma oportuna. Cada servidor coordina la interacción entre avatares y objetos de ese mundo.

Los objetos no pueden reaccionar a las entradas de los avatares u otros objetos; tienen que tener un script para cobrar vida. Normalmente, nuestra responsabilidad como desarrolladores termina al escribir la lógica de un objeto, pero en SL, la creación de un mundo activo y responsivo combina dos disciplinas del desarrollo – creación de objetos y scripting de objetos.

SL aloja una herramienta de combinación (de hecho, un IDE), tanto para crear objetos tangibles como para darles la capacidad de reaccionar a su entorno. No hay restricciones sobre el tipo de objetos que podemos soñar. Cada uno de los elementos visuales, desde la forma al material o la textura se pueden especificar y manipular. Cada cosa que creamos es una serie de polígonos simples o enlazados.

De hecho, nuestro avatar mismo y todo con lo que interactúa es un único polígono en 3 dimensiones (un “prim” en la lengua SL) o un grupo de prims enlazados. Cuando pinchamos con el botón derecho sobre un prim, aparece un menú circular que revela tanto los limitados comportamientos insertados como los que les hemos asignado mediante scripting.

La figura 1 muestra un avatar que ha pinchado con el botón derecho sobre una silla, y los conjuntos de opciones aparecen en un menú circular como trozos de tarta. Las pocas opciones disponibles son un conjunto representativo de por defecto. Una opción lógica en este caso podría ser “Sentarse Aquí” Los desarrolladores pueden añadir comportamientos más complejos adjuntando respuestas a potenciales interacciones. El scripting se hace con Linden Scripting Language.

Figura 1: Un avatar usando el menú de objetos de Segunda Vida.

LSL ha evolucionado mediante un par de iteraciones, pero actualmente parece tener un conjunto estable de API en la caja de herramientas SDK. Al estudiar la referencia de API (lslwiki.com o reflectores como http://rpgstats.com/wiki/index.php?title=Main_Page), encontraremos una API muy rica para hacer de todo, desde impartir movimiento físico, detección de colisión, y movimiento hasta conectar objetos SL a Internet.

Cómo añadir comportamientos a nuestros objetos

Pongámonos pues con el scripting. Pinchamos en el botón Build y aparece la ventana IDE. La forma en cubo y el icono Create deberían aparecer por defecto. Movemos el cursor del ratón cerca de nosotros y pasamos por “rez” un prim cúbico. Aunque son muchas las características de forma, posición y textura que podemos aplicar a un prim, conviene centrarse en el scripting LSL por el momento, empezando por una comprensión de los tipos de datos y moviéndonos a la estructura de lo que es un script.

Tipos de datos LSL

LSL soporta los tipos que aparecen en la tabla 1. Aunque algunos son obvios, otros pueden sorprendernos. A los programadores en C les resultará agradable ver el soporte explícito para operaciones de cadenas, como concatenado (mediante el operador «+») y para las operaciones normales soportadas para cadenas en Java.

|Tipo de datos|Uso|
|entero|Todo número en la gama -2.147.483.648 a 2.147.483.647.|
|flotante|Número decimal en la gama 1,175494351E-38 a 3,402823466E+38.|
|vector|Tres flotantes en forma de < x , y , z >. Normalmente una posición, color o rotación Euler. Un ejemplo de declaración es: vector a = <1,2,3>;|
|rotación|Las rotaciones consisten en cuatro flotantes en forma de < x,y,z,s >. El término s connota una medida angular.|
|clave|Una UUID (cadena especializada) empleada para identificar algo en SL, especialmente un agente, objeto, textura, otro elemento del inventario, o una solicitud del servidor de datos.|
|cadena |Una secuencia de caracteres, limitados sólo por la cantidad de memoria libre y disponible para el script.|
|listado|Una colección heterogénea de otros tipos de datos ( excluida la lista misma)|

Tabla 1: Tipos de datos LSL

Además de tipos nativos de C como integer y float, LSL también soporta de forma explícita el tipo UTF-8 string que se comporta como cabría esperar (en Java, no en C), y un tipo key para crear, manipular y representar globalmente identificadores exclusivos (GUID). No hay constantes de usuarios definidos, por tanto nada como enum..

LSL está orientado al evento, incluye estados y soporta tipos de de variables en 3 dimensiones (vector y quaternion). LSL tiene funciones incorporadas para manipular la física y las interacciones sociales entre avatares. LSL añade algunas claves interesantes; por ejemplo state, que es esencialmente un operador “go to” que fuerza una transición en un nuevo control de estado.

Para representar colecciones, LSL soporta sólo el tipo list. No hay matrices ni diccionarios, y los listados no pueden contener otros listados. Los listados en LSL son lo suficientemente molestos como para que demos aquí una descripción ampliada.

El tipo list puede contener elementos heterogéneos formados por listados de otros tipos primitivos de datos. Los listados se crean mediante valores separados por comas (CSV, por sus siglas en inglés) de los otros tipos de datos, cerrados en corchetes: «(» and «).» Una declaración de listado típica tendría el siguiente aspecto:


// a list with a two integers, a
// string, float, vector and rotation
list l = [42,0, "electric sheep",
3.1416,<1.0,2,0>,<0,0,0,1>];


Los listados guardan también meta datos sobre cada listado además de su tipo, al que se accede mediante las primitivas para acceder a datos llGetListEntryType y llCSV2List (una molestia con LSL es que cada función incorporada —y hay montones—tiene que empezar con «ll,» como si de alguna forma necesitásemos que se nos recordara de quién es el entorno de scripting que estamos usando). Los listados sólo se pueden leer mediante las funciones de acceso (en vez de una notación de paréntesis. Así, para extraer el primer elemento de la lista declarada que hemos mencionado antes y asignarlo a una cadena podríamos usar:


string element;
element = llList2String(l,0);


Se accede a los elementos tomados de los listados y se los asigna a tipo en una sola operación ; llList2Float extrae un elemento y lo asigna a float, llList2Integer asigna el elemento a integer, etc. Otro fallo más: Como los listados no pueden contener otros listados, las matrices multidimensionales son difíciles de crear y de gestionar. Una forma de solventar la falta de matrices y la falta de un modelo de objeto explícito es usando “list striding”

Un listado “strided” es sencillamente un listado con los elementos agrupados juntos de forma fija y repetitiva. Si, por ejemplo, necesitáramos una inclusión en la memoria para registrar los visitantes de nuestra tienda, dicho listado podría incluir el nombre del visitante, la cantidad de dólares Linden que se ha gastado, el artículo que ha comprado, y el número de minutos pasado en nuestro local. Aunque normalmente persistiríamos este caché a una base de datos formales, es posible que queramos un caché a corto plazo. En ese caso, podríamos usar un listado “strided”:


integer STRIDE = 4;
list patrons = ["Zeno Chambers",500, "Magic Broomstick","2006-10-31",
"Biggie Pike", 50, "Flagon of Pumpkin juice","2006-10-31",
"Mae Moriarity",25,"Halloween Hangover Kelper","2006-11-01"];


Y entonces podríamos usar una de las funciones de conveniencia de listados “strided” par ayudar en la gestión del listado. Para clasificar (de forma ascendente) un listado “strided” usaríamos:


patrons = llListSort(patrons, STRIDE, TRUE);


La estructura del Script en LSL

Si seleccionamos la pestaña Content, pinchamos con el botón derecho y seleccionamos New Script, y veremos cómo aparece un nuevo script en la ventana del editor. Debería ser idéntica al listado número 1 y la perspectiva global que nos ofrece debería parecerse a la figura 2.


1 default
2
3 state_entry()
4
5 llSay(0, "Hello, Avatar!");
6
7
8 touch_start(integer total_number)
9
10 llSay(0, "Touched.");
11
12


Listado número 1

Figura 2: Creación de un script nuevo.

La inspección de un nuevo script por defecto revela unas cuantas cosas sobre LSL. En primer lugar, LSL es esencialmente un lenguaje del tipo C, con una sintaxis aproximadamente equivalente y un flujo de control similar. Hemos de observar primero que la lógica para el objeto se halla normalmente contenida dentro de un bloque de códigos denominado “default” (“por defecto”). Cabría considerar el bloque por defecto como la “línea vacía estática” de LSL.

El módulo por defecto tiene que estar siempre presente, y representa las callbacks de eventos para el objeto en el que existe. Otros estados pueden estar presentes bien en este módulo o en otros en la carpeta de Contenidos, y es posible modular a algún otro controlador de estado (y volver) con la clave state.

El script por defecto tiene dos controles, state_entry y touch_start. Al revisar el listado global de controles de eventos en la wiki LSL, podemos ver que se invoca state_entry cada vez que se entra en el estado y cuando se crea la instancia del objeto. Se invoca Touch_start cada vez que se toca al objeto (tendremos que guardar y compilar el script y cerrar el IDE para ver los efectos del callback “touch_start” ).

En ambos controles, se invoca la función llSay; llSay emite su argumento (una cadena de texto) para cualquiera que esté a una distancia de 10 m2. Ahora que ya hemos visto el script “hello world” es hora de intentar adentrarse en aguas profundas. Eliminamos los contenidos del script para el objeto y lo sustituimos por el script del listado número 2.


1 //This script forwards all surrounding chat to the via email
2
3
4 string g_Mail_Addr = "somename@some_domain.com";
5 integer g_email = FALSE;
6 integer g_IM = FALSE;
7 integer listen_channel = 0;
8 integer command_channel = 2;
9 float g_maxtimeout = 180.0;
10 string g_emailStateOn = "Recording has been enabled!";
11 string g_emailStateOff = "Recording has been disabled!";
12 string g_IMStateOn = "IM relay has been enabled!";
13 string g_IMStateOff = "IM relay has been disabled!";
14
15 default
16
17 on_rez(integer param)
18 llResetScript();
19 //on_rez
20
21 // toggle state during the touch handler
22 state_entry() // possible to listen on more than one channel?
23 llGiveInventory(llGetOwner(), llGetInventoryName(INVENTORY_OBJECT, 0));
24 string owner = llGetOwner();
25 llListen( command_channel, "", owner, "" );
26 llListen( listen_channel, "", NULL_KEY, "" );
27 llInstantMessage(owner, g_emailStateOff+" Type: '/2 hear! ' to capture close proximity inputs.");
28 llInstantMessage(owner," Type: '/2 !hear' to disable capture.");
29 llInstantMessage(owner, " Type: '/2 IM!' to enable IM feedback.");
30 llSetTimerEvent(g_maxtimeout);
31
32 //state entry
33
34 listen( integer channel, string name, key id, string message )
35 string owner = llGetOwner();
36 if (channel == command_channel)
37 list messageContent = llParseString2List(message, (" "), ());
38 integer len = llGetListLength(messageContent);
39 message = llList2String(messageContent,0);
40 if(message == "!hear")
41 g_email = FALSE;
42 llInstantMessage(owner, g_emailStateOff);
43 //disable email
44 if(message == "hear!")
45 if (len < 2)
46 llInstantMessage(owner, "incomplete message: I need an email address too");
47 else
48 g_email = TRUE;
49 g_Mail_Addr = llList2String(messageContent,1);
50 llSetTimerEvent(g_maxtimeout);
51 llInstantMessage(owner, g_emailStateOn+" sending to "+g_Mail_Addr);
52
53 //enable email
54 if(message == "!IM") //default mode
55 g_IM = FALSE;
56 llInstantMessage(owner, g_IMStateOff);
57 //disable IM
58 if(message == "IM!")
59 g_IM = TRUE;
60 llInstantMessage(owner, g_IMStateOn);
61 //enable IM
62
63 if(g_email)
64 if(g_IM)
65 //send IM to owner of chat channel relay if on
66 llInstantMessage(owner, message);
67
68 //send email to owner of chat channel relay
69 llEmail(g_Mail_Addr, "SL Listening", message);
70 //end if(g_email)
71 // end listen
72
73 timer() // on expire of timer, discontinue
74 g_email = FALSE;
75 g_IM = FALSE;
76
77
78 //default


Listado número 2

Conexión de SL a la Vida Real

Este script muestra tanto una típica máquina finita de estado como parte de la capacidad de comunicación asíncrona de Segunda Vida. Segunda Vida soporta XML-RPC y HttpRequests. Podemos también escribir métodos de control capaces de enviar/recibir tráfico de mensajes de correo electrónico. El ejercicio muestra la interfaz del correo electrónico.

Creamos un objeto ( un “Captador de Chats”) que existe en el mundo virtual, aparentemente dormido, pero informando sobre las conversaciones que se producen en la dirección de correo que hayamos elegido. Para excluir con antelación la posibilidad de una inundación de correos, fijamos un breve temporizador para encerrar la capacidad de escucha del objeto.

El script Captador de Chats crea un canal de escucha (canal 2) y envía por correo todo lo que se vierte a la dirección de correo. Todo está contenido dentro del bloque por defecto (pero, una vez más, no tiene por qué ser así). La primera docena o así de líneas declaran e instancian útiles variables globales. El g_maxtimeout viene establecido en tres minutos, pero, si queremos, podemos experimentar con ello. El canal general de chat (g_listen_channel) es 0. Se aparta un canal privado (g_command_channel) para que el objeto escuche las órdenes de su dueño.

En la línea 17, se reajusta el script con llResetScript. Esto es buena idea, especialmente si el script va unido a un objeto que se tiene intención de vender o transferir. Al transferirlo a un nuevo propietario, cualquier listens ajustado al propietario se vuelve a ajustar, y todos los eventos pendientes se vacían cuando el nuevo propietario “pasa” el objeto por “rezz”. Tras una invocación llResetScript, se transfiere el control al bloque por defecto, y se desencadena su state_entry. Cuando escribimos y depuramos el script, podemos lograr el mismo efecto como al especificar “reset” en el editor de scripts.

Las líneas de la 22 a la 31 son las que inician el bloque del script por defecto. El script transfiere al nuevo propietario la propiedad del objeto a la que está unido. A continuación, las líneas 25-26, el objeto envía un listen por los canales 0 y 2. Luego el objeto emite dos mensajes privados al propietario del objeto, y ajusta el tiempo máximo de operación para el script (líneas 28-30). En el control listen, cada vez que se recibe un mensaje en el canal 2, el objeto lo analiza y modifica si es necesario (líneas 35-52). El objeto espera recibir uno de los mensajes de la Tabla 2 (incluido en la ventana del chat por el creador del objeto).

|Comando|Descripción|
|/2 hear! emailname@email_address|Envía cualquier conversación dentro de una proximidad del objeto a la dirección de correo según se especifica en el segundo argumento|
|/2 !hear|Cancela cualquier escucha en el canal público (canal 0).|
|/2 IM!|Envía por correo privado la conversación general (canal 0) al propietario del objeto, incluso aunque el propietario ya no esté en la proximidad de la conversación (tele-transportado a otra parte, por ejemplo).|
|/2 !IM|Cancela el envío de mensajes públicos como mensajes privados al propietario del objeto.|

Tabla 2: comandos del Captador de Chats.

En la línea 36, el oyente usa llParseString2List pra desglosar el mensaje de entrada en un listado de cadenas. El comando en sí es el elemento cero del listado, y se saca de la lista en la línea 38. Observemos que el designador de canales para mensajes (/2) no es parte de la carga de juego del mensaje, y los mensajes al canal de comando han de ir introducidos por este calificador de canales de comando.

Cualquier mensaje, del propietario de objetos o de cualquier otro que esté en proximidad, se escucha en el canal 0, y no se necesita ningún designador de canales para los mensajes de chat públicos.

Si el mensaje «hear!» está incompleto, se comprueba en las líneas 44-46, y se devuelve un mensaje privado al propietario del objeto. Si el mensaje tiene una dirección de correo, se quita esta del cuerpo del mensaje (que para entonces ya se ha analizado en un listado). La línea 38 parte el cuerpo del mensaje en una lista con espacio en blanco (whitespace) como separador. Este código no comprueba si la dirección de correo tiene una sintaxis válida, pero se podría hacer con facilidad girando la cadena en una lista con el signo @ como operador, y mirando la longitud de la lista.

Las líneas 53-66 completan el procesado del canal de comandos para conectar o desconectar la mensajería privada. En la línea 68, se envía un mensaje de correo a la dirección de correo que se proporciona.

Podemos probarlo con cualquier objeto que creemos – pongamos, una pelota de playa que anima a que la gente la vaya pasando, y tendremos una en nuestro inventario por cortesía de Linden Lab. Puede que algunos terrenos de propiedad privada en Segunda Vida no nos permitan instanciar el objeto.

Conclusión

Segunda Vida está llena de oportunidades para crear útiles y hermosos artefactos con una gama ilimitada de comportamientos. Podemos probar a tomar clases en ese mundo, anunciarnos para conocer a otros desarrolladores y unirnos a uno de los muchos grupos de desarrolladores que hay en ese mundo. En poco tiempo encontraremos que nos hallamos entre la elite creativa de los desarrolladores de Segunda Vida.