Repositorio Institucional de Documentos

Implementaci´on de un sistema de “test multi-jugador de cruce perceptual” PROYECTO DE FIN DE CARRERA Autor: David Gracia Larrod´e Director: Manuel Gonz´alez Bedia Codirector: Francisco Ser´on Arbeloa Ingenier´ıa en Inform´atica Curso 2012-2013 Departamento de Inform´atica e Ingenier´ıa de Sistemas Escuela de Ingenier´ıa y Arquitectura Universidad de Zaragoza Junio de 2013 Implementaci´on de un sistema de “test multi-jugador de cruce perceptual” RESUMEN El objetivo de este proyecto de fin de carrera es conseguir un marco de ejecuci´on virtual para experimentos de cruce perceptual (paradigma para la realizaci´on de experimentos de cognici´on social, basado en los trabajos realizados en la universidad francesa de Compi`egne en 2009 de Auvray, Lenay y Stewart[5]). Se desarrollar´a una aplicaci´on virtual a la que se acceder´a desde computadoras situadas en habitaciones separadas. Cada participante modificar´a la posici´on de un cursor en la pantalla a lo largo de una l´ınea mediante el movimiento transversal de su rat´on, y recibir´a un est´ımulo en el momento en que el cursor se cruce con un objeto durante su movimiento. Los sujetos podr´an cruzarse con dos tipos de cosas: el cursor real del otro participante (persona) o con el cursor de un objeto artificial (m´ovil o fijo). Se les pide a los sujetos que sean capaces de identificar cu´ando la interacci´on establecida es con el humano y cuando no. Para dar soluci´on al objetivo planteado se implementar´a una aplicaci´on web, que trabajar´a sobre un servidor que soporte la tecnolog´ıa WebSockets, que aporta un canal de intercambio de informaci´on bidireccional real entre el servidor y el cliente en tiempo real. El experimento se plantea sobre una red local para minimizar la latencia en la comunicaci´on. Para la construcci´on del ”front-end” se utilizar´a una combinaci´on de HTML5, CSS y JavaScript. Se construir´a un framewok que permita realizar experimentos formados, por un lado, por dos contrincantes (persona vs persona o persona vs bot) y, por otro, por m´ultiples participantes, donde cada persona se enfrentar´a a otro participante (persona), a un objeto m´ovil y a un objeto fijo. En el primer tipo de experimento, al terminar cada prueba, el sujeto debe responder si ha interactuado con otra persona o con un objeto artificial. En el segundo tipo, durante la prueba, el sujeto podr´a hacer click cuando crea que esta interactuando con un igual. El tipo de objeto m´ovil, en el segundo caso, podr´a ser la sombra del oponente humano con cierto retardo en tiempo o a una distancia marcada. Con esta plataforma se pretenden analizar todos los aspectos presentes en un intercambio comunicativo humano puesto que existen elementos que se refieren a las contingencias de la interacci´on que nos permiten identificar que una comunicaci´on real se est´a produciendo. Pretendemos analizar las propiedades que permiten a los interlocutores construir patrones de interacci´on comunes que les hagan regular mutuamente sus acciones. i Para mi abuelo Agustin. Por hacerlo posible. iii Agradecimientos A mi familia, mi novia y mis amigos por su apoyo y cari˜no. A los dos Carlos, Daniel y Gonzalo por ayudarme. A Manuel y Paco por confiar en mi. Gracias. v ´ Indice general I Memoria XVII 1. Introducci´on 1 1.1. Objetivo y alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Contexto en el que se realiza el proyecto . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Metodolog´ıa: Desarrollo ´agil de software . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Trabajo a realizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.6. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7. Planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Estado del arte 7 2.1. Cognici´on social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Teor´ıa de la Mente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Nueva corriente de pensamiento. Superando la Teor´ıa de la Mente cl´asica . 9 2.2. Cruce perceptual: paradigma de interacci´on m´as simple . . . . . . . . . . . . . . . 10 2.3. Modelo de detecci´on de agentes sociales . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4. Extensiones y Modelos del Paradigma de cruce perceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Tecnolog´ıas utilizadas para implementaci´on de la aplicaci´on 23 3.1. Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1. HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.2. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.3. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2. Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4. Descripci´on de la aplicaci´on 27 4.1. Descripci´on general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2. Descripci´on elementos de juego.html . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3. Descripci´on de una ronda y estados de la aplicaci´on cliente . . . . . . . . . . . . . 31 4.4. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5. Modos de juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.6. Modos de un bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.7. Errores tratados gr´aficamente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.8. Visor de gr´aficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Resultados 35 5.1. Informaci´on almacenada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2. Descripci´on medici´on de prestaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Experimento modo normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.1. Informaci´on de las visitas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 vii xiv ´ Indice de tablas 2.1. Distribuci´on de los clicks y de las simulaciones t´actiles. [Extra´ıdo de Lenay y Stewart, 2012[26]] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Resumen de los estudios experimentales y de modelado m´as importantes de cruce perceptual. [Extra´ıdo de Auvray y Rohde, 2012[4]] . . . . . . . . . . . . . . . . . . 19 4.1. Tabla con los par´ametros de configuraci´on y su descripci´on. . . . . . . . . . . . . . 28 5.1. Tabla porcentajes de acierto y fallo seg´un el tipo de bot. . . . . . . . . . . . . . . 37 A.1. Ejemplos de uso de selectores de jQuery . . . . . . . . . . . . . . . . . . . . . . . . 48 A.2. Esta tabla presenta el software del lado del servidor que soporta el protocolo WebSockets, clasificado por lenguaje de implementaci´on. [Extra´ıdo de http://en.wikipedia.org/wiki/WebSocket] 51 A.3. Tabla de diferencias entre HTML5 y HTML4 (parte 1). En amarillo aquellas etiquetas introducidas en esta nueva versi´on, en azul las etiquetas que han sido cambiadas todo o en parte y en gris las etiquetas eliminadas de esta versi´on. Si bien en la pr´actica los navegadores no lo est´an teniendo en cuenta para evitar perder cuota de mercado. [Extra´ıdo de http://es.wikipedia.org/wiki/HTML5] . . . . . . . . . . . . 52 A.4. Tabla de diferencias entre HTML5 y HTML4 (parte 2). En amarillo aquellas etiquetas introducidas en esta nueva versi´on, en azul las etiquetas que han sido cambiadas todo o en parte y en gris las etiquetas eliminadas de esta versi´on. Si bien en la pr´actica los navegadores no lo est´an teniendo en cuenta para evitar perder cuota de mercado. [Extra´ıdo de http://es.wikipedia.org/wiki/HTML5] . . . . . . . . . . . . 53 A.5. Tabla de diferencias entre HTML5 y HTML4 (parte 3). En amarillo aquellas etiquetas introducidas en esta nueva versi´on, en azul las etiquetas que han sido cambiadas todo o en parte y en gris las etiquetas eliminadas de esta versi´on. Si bien en la pr´actica los navegadores no lo est´an teniendo en cuenta para evitar perder cuota de mercado. [Extra´ıdo de http://es.wikipedia.org/wiki/HTML5] . . . . . . . . . . . . 54 D.1. Estructura del tipo de mensaje configurationInfo, con comentarios de sus componentes. 85 D.2. Estructura del fichero configuration.json, con comentarios de sus componentes. . 86 D.3. Estructura del tipo de mensaje pairingInfo, con comentarios de sus componentes. . 86 D.4. Estructura del tipo de mensaje statusInfo, con comentarios de sus componentes. . 87 D.5. Estructura del tipo de mensaje errorInfo, con comentarios de sus componentes. . . 87 D.6. Estructura del fichero roundInfo, con comentarios de sus componentes. . . . . . . . 88 D.7. Estructura del fichero roundMMInfo, con comentarios de sus componentes. . . . . 89 D.8. Estructura del tipo de mensaje replyInfo, con comentarios de sus componentes. . . 90 D.9. Estructura del tipo de mensaje motionInfo, con comentarios de sus componentes. . 90 E.1. Tabla de caracter´ısticas del PC1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 E.2. Tabla de caracter´ısticas del PC2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 F.1. Informaci´on de la aplicaci´on desarrollada en el proyecto. . . . . . . . . . . . . . . . 99 xv F.2. Informaci´on del experimento Auvray et al. (2009)[5]. . . . . . . . . . . . . . . . . . 100 xvi Parte I Memoria xvii Cap´ıtulo 1 Introducci´on 1.1. Objetivo y alcance del proyecto En los ´ultimos a˜nos, la investigaci´on en Cognici´on Social se ha interesado por fen´omenos de interacci´on humana que no pueden entenderse en funci´on de capacidades individuales propias de los agentes que se encuentran en la interacci´on. Aparentemente, existen procesos aut´onomos de coordinaci´on din´amica que s´olo emergen cuando dos o m´as sujetos participan en una interacci´on en tiempo real. A partir de trabajos realizados en la universidad francesa de Compi`egne en 2009 (Auvray, Lenay y Stewart, 2009[5]) se desarroll´o un modelo m´ınimo para la realizaci´on de experimentos de cognici´on social donde se analizaba la interacci´on que dos sujetos manten´ıan en una comunicaci´on ciega a trav´es de un dispositivo electromec´anico, estableci´endose la definici´on del paradigma de cruce perceptual. Estudios posteriores profundizaron m´as en detalle en el paradigma (Lenay et al., 2012[26]; Auvray y Rhode, 2012[4]) y otros analizaron modelos de simulaci´on de esta tarea (Iizuka y Di Paolo de 2007[25], Di Paolo et al, 2008[11]) con el fin de explicar los diferentes patrones generados. Con este proyecto de fin de carrera se pretende conseguir un marco de ejecuci´on virtual para experimentos de cruce perceptual con el objetivo de poder realizar medidas que no son sencillas de implementar en la configuraci´on original. Se desarrollar´a una aplicaci´on virtual a la que se acceder´a desde computadoras situadas en habitaciones separadas. Cada participante modificar´a la posici´on de un cursor en la pantalla a lo largo de una l´ınea mediante el movimiento transversal de su rat´on, y recibir´a un est´ımulo en el momento en que el cursor se cruce con un objeto durante su movimiento. Los sujetos podr´an cruzarse con dos tipos de cosas: el cursor real del otro participante (persona) o con el cursor de un objeto artificial (m´ovil o fijo). En caso de lograr el escenario original, que no ten´ıa ning´un acceso visual al monitor e interactuaba con dos se˜nales id´enticas, los sujetos deben ser capaces de identificar cu´ando la interacci´on establecida es con un humano y cuando con un objeto artificial. Para dar soluci´on al objetivo planteado se implementar´a una aplicaci´on web, que trabajar´a sobre un servidor que soporte comunicaci´on de datos en tiempo real. Dicho servidor debe dar soporte a la tecnolog´ıa WebSockets, que aporta un canal de intercambio de informaci´on bidireccional y as´ıncrono entre el servidor y el cliente. El experimento se plantea sobre una red local para que la inevitable latencia por el paso de mensajes entre los terminales sea la m´ınima posible. Para la parte del ”front-end” se utilizar´a una combinaci´on de HTML5, CSS y JavaScript. 1 En primer lugar se construir´a un framewok simple para realizar experimentos de cruce perceptual, los experimentos estar´an formados ´unicamente por dos personas, una contra otra. En segundo lugar se implementar´a un framewok partiendo del anterior que permita experimentos persona contra persona y persona contra bot. En este marco seguimos teniendo un integrante por lado del experimento, pero se a˜nade un nuevo tipo de participante, el bot. Se crear´an diferentes tipos de bots, unos enviar´an posiciones aleatorias, otros representar´an la traza de movimientos de un experimento anterior, otros seguir´an una pol´ıtica de movimiento seg´un la posici´on del participante humano y finalmente otros repetir´an los movimientos que este haciendo su oponente humano con un cierto retardo en tiempo. Al final de cada experimento cada persona deber´a afirmar si ha interactuado con otra persona o con una m´aquina. En tercer lugar se a˜nadir´a funcionalidad al framewok anterior permitiendo realizar experimentos con m´as de un integrante por lado de los mismos. Para ser m´as exactos cada participante humano se enfrentar´a a otro participante humano, a un objeto m´ovil y a un objeto fijo. Durante el experimento la persona podr´a hacer click cuando crea que esta interactuando con otra persona. El objeto m´ovil, un bot, en primera instancia ser´a un bot sombra del oponente humano con un cierto retardo en tiempo, un tipo de bot ya creado en la anterior etapa de implementaci´on. Posteriormente se crear´a otro tipo de experimento con m´ultiples componentes, en el cu´al se cambiar´a el tipo de bot sombra, por otro que realice la misma traza de movimientos que el oponente humano pero con una diferencia de distancia impuesta. Con esta plataforma se pretenden analizar todos los aspectos presentes en un intercambio comunicativo humano puesto que existen elementos que se refieren a las contingencias de la interacci´on que nos permiten identificar que una comunicaci´on real se est´a produciendo. Pretendemos analizar las propiedades que permiten a los interlocutores construir patrones de interacci´on comunes que les hagan regular mutuamente sus acciones. 1.2. Contexto en el que se realiza el proyecto La cognici´on social constituye en la actualidad un ´area de gran inter´es en diversos campos de la psicolog´ıa, siendo m´ultiples los trabajos que se han preocupado por delimitar su concepto y desarrollo. La cognici´on social incluye aspectos tanto “sociales” como “cognitivos” de la representaci´on del mundo en las mentes de las personas, y por tanto, es un concepto m´as amplio que el de Teor´ıa de la Mente o ToM1. No obstante, ambos conceptos hacen referencia a la destreza cognitiva que capacita a los humanos para informar de los estados mentales propios y de las otras personas (creencias, deseos, emociones, intenciones), y entender que estas representaciones basadas en sensaciones y percepciones, no siempre se corresponden con la realidad (Astington, Harris y Olson, 1988[3]). Por consiguiente, la cognici´on social es esencial para predecir y explicar el comportamiento de las personas (Astington, 1993[2]; Flavell y Miller, 1998[14]), tanto en el plano de la acci´on (Mitchell, 1997[31]) como en el comunicativo (Bishop, 1997[7]; Sperber y Wilson, 2002[39]). Sin embargo, en interacciones espec´ıficas como parecen existir en los fen´omenos de atribuci´on de “emociones” entre interlocutores en una conversaci´on, se puede ver que no partimos de la observaci´on sensorial de los movimientos corporales y faciales (la posici´on, orientaci´on, tono de voz, gestos, sonrojo,...) para deducir lo que est´a sintiendo el otro, sino que reconocemos las emociones ajenas de manera directa, espont´anea y sin ning´un tipo de an´alisis, al mismo tiempo que se genera en nosotros un sentimiento similar por empat´ıa. Por tanto, en nuestras interacciones sociales se expresan capacidades interactivas b´asicas, que recogen la perspectiva de quien forma parte de esa situaci´on comunicativa, y capacidades inferenciales abstractas, que analizan lo dicho y pueden desplegarse, sin necesidad de participar efectivamente de la interacci´on. 1de la abreviatura del ingl´es Theory of Mind, propuesto originalmente por Premack y Woodruff (1978)[34] 2 Los investigadores de la cognici´on social son cada vez m´as conscientes de que hay muchos fen´omenos que no se pueden entender mediante la investigaci´on de las situaciones “off-line”. El paradigma de cruce perceptual de Auvray et al (2009)[5] ofrece el paradigma m´as sencillo para el estudio de estas interacciones en l´ınea: dos personas, un espacio unidimensional, un bit de informaci´on, y una respuesta tipo s´ı / no. 1.3. Metodolog´ıa: Desarrollo ´agil de software Este proyecto naci´o a partir de una propuesta de pr´acticas que luego se convirti´o en proyecto de fin de carrera. Por ello, alej´andome del modelo cl´asico de desarrollo de software (requerimientos, an´alisis, dise˜no, implementaci´on, ...), decid´ı optar por un tipo de metodolog´ıa m´as ´agil y pr´actico, que tan de moda se est´a poniendo en la actualidad. He ido desarrollando mi trabajo marc´andome una serie de hitos que, en si mismos, tuvieran visibilidad funcional. Es decir, una vez conseguido el objetivo marcado por el hito, tendr´ıa algo que poder mostrar y poner en funcionamiento. Esto permite introducir cambios clave que en una metodolog´ıa cl´asica no se podr´ıan a˜nadir hasta el fin del proceso y vuelta a empezar. Un ejemplo ser´ıa que si quisiera implementar una web para vender un producto, me marcar´ıa como primer objetivo fabricar una web con un bot´on que permita a un usuario comprar de un ´unico tipo de producto una cantidad fijada del mismo, en vez de plantearme si debo construir la base de datos, montar un servidor, dise˜nar la p´agina web, etc. Durante las distintas etapas de consecuci´on de un objetivo marcado, he intentado seguir la filosof´ıa “Less talking More doing” (“Menos hablar y m´as hacer”), por lo que me documentaba y aprend´ıa lo suficiente como para ponerme en el menor tiempo posible a implementar una soluci´on. No realizaba siempre una misma estructura de pasos a seguir para alcanzar mi meta (metodolog´ıa flexible), ya que cada tarea me exig´ıa un grado diferente de esfuerzo. Si tuviera que dar un esquema general de pasos a seguir, ser´ıa el siguiente: 1. Una vez marcado el hito a conseguir, dividir en tareas el trabajo a realizar de forma l´ogica. 2. Documentarse lo suficiente para poder empezar implementar una tarea. 3. Realizar la tarea. Si se encuentra alg´un problema volver a documentarse para resolverlo. 4. Si a´un faltan tareas por realizar, volver al paso 2 con la tarea siguiente, si no continuar al siguiente paso. 5. Comprobar el buen funcionamiento de la tarea en su conjunto antes de ense˜n´arsela al cliente (en mi caso el director del proyecto). 1.4. Trabajo a realizar Para alcanzar el objetivo de este proyecto, que es conseguir un marco de ejecuci´on virtual para experimentos de cruce perceptual, se realizar´an las siguientes tareas: 1. En primer lugar se construir´a un framewok simple para realizar experimentos de cruce perceptual, los experimentos estar´an formados ´unicamente por dos personas, una contra otra. Esta primera construcci´on servir´a de base a las siguientes implementaciones. 3 2. En segundo lugar se implementar´a un framewok partiendo del anterior que permita experimentos“persona contra persona”y“persona contra bot”. En este marco seguimos teniendo un integrante por lado del experimento, pero se a˜nade un nuevo tipo de participante, el bot. Se crear´an diferentes tipos de bots, unos enviar´an posiciones aleatorias, otros representar´an la traza de movimientos de un experimento anterior, otros seguir´an una pol´ıtica de movimien- to seg´un la posici´on del participante humano y finalmente otros repetir´an los movimientos que este haciendo su oponente humano con un cierto retardo en tiempo. Al final de cada experimento cada persona deber´a afirmar si ha interactuado con otra persona o con una m´aquina. 3. En tercer lugar se a˜nadir´a funcionalidad al framewok anterior permitiendo realizar experimentos con m´as de un integrante por lado de los mismos. Para ser m´as exactos cada participante humano se enfrentar´a a otro participante humano, a un objeto m´ovil y a un objeto fijo. Durante el experimento la persona podr´a hacer click cuando crea que esta interactuando con otra persona. El objeto m´ovil, un bot, en primera instancia ser´a un bot sombra del oponente humano con un cierto retardo en tiempo, un tipo de bot ya creado en la anterior etapa de implementaci´on. Posteriormente se crear´a otro tipo de experimento con m´ultiples componentes, en el cu´al se cambiar´a el tipo de bot sombra, por otro que realice la misma traza de movimientos que el oponente humano pero con una diferencia de distancia impuesta. 4. Por ´ultimo, implementar´e un visor de gr´aficas, que permita el estudio de la informaci´on acumulada durante los experimentos. 1.5. Herramientas utilizadas La herramientas que se han utilizado a lo largo del desarrollo de la aplicaci´on, atendiendo a su funcionalidades, han sido las siguientes: Entorno de programaci´on para el desarrollo de la aplicaci´on web.  Eclipse Java EE IDE for Web Developers. Versi´on: Juno Service Release 1, con un plug-in para Maven Trazado de bocetos y construcci´on de esquemas y figuras.  Evolus Pencil versi´on 2.0.2 Editores de HTML, usados sobretodo al principio, antes de a˜nadir el servidor, para construir las paginas web y posteriormente como bancos de pruebas para funcionalidades de HTML5, JavaScript y CSS.  Notepad++ (m´as usado), ´ultima versi´on 5.9.6.2  HTML-Kit 292  BlueGriffon versi´on 1.5.2  Komodo Edit versi´on 7.1.3 Biblioteca para facilitar el uso de JavaScript.  jQuery versi´on compacta “jquery-1.8.3.min.js” Construcci´on visores de gr´aficas.  Easy Java Simulations versi´on 4.3.7 4 1.6. Estructura del documento La estructura de esta memoria esta dividida en seis cap´ıtulos, incluyendo este cap´ıtulo introductorio. En el cap´ıtulo 2 se define el contexto en el que se mueve la aplicaci´on y descripci´on de experimentos relacionados con el paradigma de cruce perceptual. En el cap´ıtulo 3 se describe la tecnolog´ıa utilizada para la implementaci´on de la aplicaci´on distinguiendo entre las distintas partes de la misma. En el cap´ıtulo 4 se describe la aplicaci´on desarrollada. En el cap´ıtulo 5 se describe la informaci´on almacenada por la aplicaci´on para su posterior tratamiento y resultados obtenidos de la medici´on de prestaciones temporales de la misma. En el cap´ıtulo 6 se recogen las conclusiones extra´ıdas durante el desarrollo del proyecto y las diferentes l´ıneas de trabajo futuro. 1.7. Planificaci´on Durante los 7 meses de duraci´on del proyecto, se han realizado las tareas que se muestran en el diagrama de Gantt contenido en la figura 1.1. Es necesario se˜nalar que, por la metodolog´ıa seguida a la hora de llevar a cabo el desarrollo, dentro de cada etapa de implementaci´on existe un tiempo variable paralelo de documentaci´on. Figura 1.1: Diagrama de Gantt de las actividades realizadas. 5 2. La reducci´on de la entrada sensorial obliga a un despliegue espacial y temporal de las actividades de percepci´on, y esto hace que sea posible grabar y analizar en detalle. 3. La simplicidad de la configuraci´on hace posible dilucidar las condiciones suficientes para un esquema explicativo detallado de la din´amica colectiva, que se espera tenga cierta generalidad. Los resultados para todos los participantes y todas las sesiones mostraron que la mayor´ıa de los clicks (62 %) se produjo cuando los dos socios estaban uno frente al otro, es decir, en una situaci´on de cruce perceptual. (Ver figura 2.3). Figura 2.3: Distribuci´on de frecuencias en funci´on de la distancia entre los campos receptores de los dos participantes. La l´ınea negra representa la frecuencia total de clicks realizados: el 62 % de la distribuci´on se encuentra entre ± 30 p´ıxeles. La l´ınea roja representa la frecuencia total de est´ımulos recibidos por los sujetos: el 28 % de la distribuci´on se encuentra entre ± 30 p´ıxeles. En ambos casos, hay un pico claro en torno a la distancia de 0 p´ıxeles, es decir, la situaci´on de cruce perceptual, lo que demuestra que hay un atractor en este punto, al menos en el d´ebil sentido descriptivo una vez que los sujetos han alcanzado la situaci´on de cruce perceptual tienden a permanecer en esta configuraci´on din´amica estable. Un pico menor a la distancia de 50 p´ıxeles (marcado con una flecha) se corresponde con el se˜nuelo m´ovil. [Extra´ıdo de Lenay y Stewart, 2012[26]] A continuaci´on, se analiz´o la distribuci´on de clicks como una funci´on de la causa de los est´ımulos recibidos por el participante durante los precedentes 2 segundos. Los resultados de todos los participantes muestran que el 66 % ( ± 4) de los clicks siguen los est´ımulos de cruce perceptual; el 23 % ( ± 10) de los clicks siguen los est´ımulos debidos al se˜nuelo m´ovil, y s´olo el 11 % ( ± 9) siguen est´ımulos provocados por el se˜nuelo fijo. Estos resultados muestran que los participantes son capaces de distinguir entre las tres categor´ıas de objetos que se encuentran en el espacio unidimensional. Distinguen entre el campo receptor de la pareja y un objeto, ya sea fijo o m´ovil. Este ´exito global puede parecer sorprendente, ya que, por construcci´on, el se˜nuelo m´ovil tiene exactamente los mismos movimientos que el campo receptor de su pareja. Parece que lo que se reconoce es, de hecho, la actividad perceptual del sujeto, y no s´olo la estructura objetiva de los movimientos (Wilkerson, 1999[44]). Sin embargo, un an´alisis m´as detallado muestra que este aparente ´exito a nivel general oculta lo que era en realidad un fracaso a nivel individual. 12 En primer lugar, se llev´o a cabo una comparaci´on entre la distribuci´on de los clicks y la distribuci´on de los est´ımulos t´actiles recibidos. Los resultados globales para todos los participantes muestran que el 52 % ( ± 12) de los est´ımulos provienen de un cruce perceptual, el 33 % ( ± 12) provienen del se˜nuelo fijo, y s´olo el 15 % ( ± 6) del se˜nuelo m´ovil (Ver tabla 2.1; figura2.3). Tabla 2.1: Distribuci´on de los clicks y de las simulaciones t´actiles. [Extra´ıdo de Lenay y Stewart, 2012[26]] Cuando se calcula la ratio de clicks/est´ımulos, nos encontramos con 0,33 para el se˜nuelo fijo, 1,26 para el cruce perceptual, y 1.51 para el se˜nuelo m´ovil. Estos resultados muestran una diferencia importante entre el se˜nuelo fijo por un lado (0.33) y las entidades m´oviles por el otro (1,26 y 1,51). Los participantes tienen una probabilidad de hacer click que es cuatro veces mayor si la estimulaci´on proviene de una entidad m´ovil que si es debida al se˜nuelo fijo. Por lo tanto, la ratio entre clicks y est´ımulos muestra que, en general cada participante no parece distinguir entre est´ımulos debidos a cruce perceptual y est´ımulos debidos al se˜nuelo m´ovil (1,26 vs 1,51). La diferencia en los clicks en el se˜nuelo m´ovil y en el campo receptor de la pareja (23 vs 66 %) parece deberse s´olo a las estrategias de los movimientos, tales que, los encuentros con el se˜nuelo m´ovil son mucho menos frecuentes que los encuentros debidos al cruce perceptual (15 vs 52 %). Si los participantes tienen ´exito en la tarea, es esencialmente porque logran situarse cara a cara con su contrincante, y no porque reconozcan en el patr´on de estimulaci´on alguna pista con la que discriminar el campo receptor de la pareja del se˜nuelo m´ovil. La ´unica diferencia reside en la interacci´on en s´ı misma. Con el fin de dar cuenta de estos resultados, hay dos cosas que deben ser explicadas. Por un lado, la capacidad de los participantes a encontrar situaciones de estar “cara a cara” y, por otro lado, las razones que les lleva a hacer click. a) Atractor en din´amicas colectivas Cabe se˜nalar que todas las observaciones realizadas con estas configuraciones muestran que la percepci´on de un objeto en una posici´on es determinada mediante su exploraci´on activa y reversible: los sujetos van y vienen alrededor de la singularidad que provoca un retorno sensorial (Sribunruangrit et al. , 2004[40]). Por lo tanto, hay una estrategia general que consiste en invertir el movimiento del campo receptor despu´es de un evento sensorial. En la medida en que la estrategia de percepci´on de cada participante consiste en invertir su movimiento despu´es de una alteraci´on en la entrada sensorial, si un participante se encuentra con su contrincante invertir´a su movimiento mientras que el segundo har´a lo mismo. Los dos campos receptores entrar´an, por lo tanto, en una “especie de danza”. Esto puede describirse como un atractor en la din´amica colectiva; un atractor que no es un punto fijado espacialmente, sino una regi´on que puede ser desplazada. A pesar de que los participantes no tienen un objetivo espec´ıfico de colaboraci´on, los esfuerzos simult´aneos para discriminar la presencia de su pareja producen un atractor en las din´amicas colectivas de sus actividades perceptivas (Froese y Di Paolo, 2010[18], 2011a[17]). 13 b) Las razones que llevan a los sujetos a hacer click Si se estudia los acontecimientos que preceden a cada click, se observa que si en los ´ultimos 2 segundos de su actividad perceptiva un sujeto se encuentra: 1. pocos est´ımulos, no se constituye la percepci´on y la probabilidad de hacer click es baja; 2. muchos est´ımulos, pero para un objeto que se reconoce como fijo (estabilidad sensomotora), la probabilidad de hacer click es de nuevo bajo; 3. pero si hay muchos est´ımulos, para un objeto que permanece indeterminado espacialmente, la probabilidad de hacer click es alta (ver figura 2.4). Figura 2.4: Probabilidad de hacer click. La probabilidad de que los participantes hagan click, se representa gr´aficamente en funci´on del n´umero de estimulaciones distintas recibidas durante los ´ultimos 2 segundos. Tri´angulos: est´ımulos totales (cuerpo-objeto, objeto fijo y atractivo m´ovil); Cuadrados: est´ımulos debido a encuentros con el objeto fijo; Rombos: est´ımulos debido a los encuentros con un objeto en movimiento (avatar o se˜nuelo m´ovil). Las barras de error representan los errores est´andar de las medias. [Extra´ıdo de Lenay y Stewart, 2012[26]] En este ´ultimo caso, es probable que el objeto sea el del otro participante, pero tambi´en es posible que sea el del se˜nuelo m´ovil. As´ı, los clicks de los participantes se pueden explicar en gran medida por la conjunci´on de dos criterios, uno negativo y uno positivo: 1. ”Otro sujeto” es algo que se resiste a la determinaci´on espacial precisa: no es ni un objeto fijo, ni un objeto con movimientos determinados por una regla simple. 2. Sin embargo, al mismo tiempo, ”otro sujeto” es algo que mantiene su presencia. Esta es de hecho una caracter´ıstica del objeto-cuerpo del otro participante, pero no del se˜nuelo m´ovil, debido a que es s´olo este objeto-cuerpo el que tiene un campo receptor sensible a su vez a la presencia de objetos, es decir, es probable que cambie su comportamiento de acuerdo a la entrada sensorial que recibe. La (´unica) diferencia entre el campo receptor del otro participante y el se˜nuelo m´ovil unido a ´el, es que s´olo el primero es sensible a mi presencia, y como se ha visto, esta sensibilidad est´a vinculada a una intencionalidad perceptiva que pretende continuamente permanecer cerca de una singularidad. Esta es precisamente una condici´on suficiente para la formaci´on de un atractor en la din´amica conjunta lo cual tiende a aumentar la probabilidad de que el compa˜nero este presente. Por lo tanto, el criterio que parece estar al servicio de los participantes para hacer click no es arbitrario, sino que se produce l´ogicamente de la reuni´on de dos intencionalidades. Este criterio es coherente con el contenido mismo de lo que ha de ser reconocido. El otro sujeto es reconocido s´olo como algo que se resiste a su determinaci´on precisa y, sin embargo, que persiste en estar presente. 14 Sin embargo, incluso si este criterio parece razonable, no hay suficiente garant´ıa de distinguir entre el campo receptor de la pareja y el se˜nuelo m´ovil. Si por un golpe de mala suerte es el se˜nuelo m´ovil el que permanece presente, los participantes tienen la misma probabilidad de hacer click que en el campo receptor. Por ejemplo, si el campo receptor de mi contrincante se dedica a oscilar alrededor de un objeto situado a 50 p´ıxeles desde mi posici´on, y que provoca un movimiento del se˜nuelo alrededor de mi propia posici´on, voy a ser inducido a hacer click en el se˜nuelo. Conclusi´on del experimento En este experimento en el que el objetivo es discriminar la presencia de otro sujeto, los individuos fallan mientras que la acci´on colectiva tiene ´exito. As´ı, el ´exito colectivo no puede explicarse por la capacidad individual de reconocer otro sujeto por medio de una sensaci´on particular (Michael y Overgaard, 2012[30]). El ´exito colectivo se explica principalmente por una din´amica colectiva que resulta de la participaci´on de cada individuo en su actividad perceptiva en busca de un compa˜nero. Los clicks provienen de una regla de decisi´on que parece ser prudente, pero que es insuficiente a nivel individual para distinguir entre las sensaciones espec´ıficas. 2.3. Modelo de detecci´on de agentes sociales Iizuka y Di Paolo (2007)[25] elaboraron un modelo m´ınimo de cruce perceptual inspirado por los experimentos de Murray y Trevarthen (1985)[32] y en los trabajos de Auvray et al (2009)[5]. Dos agentes movi´endose a derecha e izquierda deben interactuar cruzando sus sensores individuales en varias ocasiones. Sin embargo, si se le presenta una grabaci´on de una interacci´on previa, el agente vivo debe alejarse de ella. Una descripci´on m´as detallada del estudio se presenta a continuaci´on. a) Modelo acoplado Los agentes est´an obligados a discriminar si otro agente es un compa˜nero de interacci´on en vivo o una grabaci´on de la conducta del agente mediante el uso de sensores y motores m´ınimamente restringido. Los dos agentes, superior e inferior, se enfrentan entre s´ı en un espacio ilimitado unidimensional. Cada agente s´olo puede moverse a izquierda y derecha horizontalmente. Un sensor de encendido/apagado est´a unido en el centro del agente y esta activado, por ejemplo, estableci´endose en 1 cuando se cruza con la pareja, mientras que se establece en 0 en caso contrario. Con una cierta probabilidad la informaci´on sensorial salta a un estado diferente (la probabilidad se establece en 0,05) en cada paso temporal del m´etodo de Euler como ruido sensorial. La presencia de ruido jugar´a un papel importante para los agentes para lograr la tarea, tal como se explicar´a m´as adelante. Figura 2.5: Esquema agentes superior e inferior. [Extra´ıdo de Iizuka y Di Paolo, 2007[25]] 15 b) Agentes m´oviles Los agentes est´an controlados por una red neuronal recurrente de tiempo continuo (CTRNN), la cual consiste en 8 nodos totalmente conectados en el modelo. El tiempo de evoluci´on de los estados de las neuronas se expresa mediante: τi˙yi=−yi+ N X j=1 wji ∗z(yj) + Ii, z(x)=1/(1 + e−x−bi) Donde yirepresenta el potencial de la c´elula de la neurona i, zies la tasa de disparo,τi(rango [1,100]) es su constante temporal, bi(rango [-3,3]) es un t´ermino de sesgo, y wij (rango [-8 , 8]) es el peso de la conexi´on de la neurona, j, a la neurona i. Iirepresenta la entrada sensorial, que da s´olo a una neurona sensorial. El n´umero de neuronas, N, se establece en 8. La informaci´on sensorial se calcula multiplicando 1/0 (on / off) de se˜nal por un par´ametro de ganancia (rango [1, 100]), que est´a codificado gen´eticamente. Hay dos neuronas efectoras para controlar la actividad motora. Del mismo modo, la salida del motor se calcula a partir de la diferencia de las tasas de disparo de las neuronas efectoras, que corresponde a una rango de [-1,1] y es entonces multiplicada por un par´ametro de ganancia (rango [1, 100]). c) Configuraci´on evolutiva Los agentes se desarrollaron utilizando un algoritmo gen´etico con elitismo. Se diferencian agentes en dos grupos: los representados en la parte superior y la parte inferior de la figura 2.5. Con el fin de permitir que cada grupo de agentes tenga diferentes estrategias de comportamiento, se usan dos poblaciones. Cada poblaci´on tiene 20 agentes, que se eval´uan mediante la interacci´on con los mejores 5 agentes de otra poblaci´on. En cada poblaci´on, todos los par´ametros de la red neuronal y las ganancias est´an representadas por un vector de valores reales ([0,1]) que se decodifica linealmente al rango correspondiente a los par´ametros. Se utilizan operadores de intercambio gen´etico y de vectores de mutaci´on, que a˜naden un peque˜no vector aleatorio con el genotipo de valor real. Los mejores 5 agentes de la poblaci´on se conservan y 10 agentes se sustituyen por agentes con mutaci´on que son seleccionados de las poblaciones originales basadas en una funci´on de adecuaci´on (fitness) y los 10 agentes restantes se sustituyen mediante cruce gen´etico entre dos agentes seleccionados. La funci´on de adecuaci´on o fitness, que puede observarse en la figura 2.6, se calcula sobre la base de dos factores. Uno de ellos es la cantidad de veces que el agente puede cruzar su posici´on central con la de un agente de interacci´on en vivo. La otra es cuanto puede el agente mantenerse alejado de un agente ficticio que s´olo reproduce los movimientos de su pareja, registrados en la primera etapa (interacci´on unidireccional). Ambas condiciones comienzan a partir de las mismas configuraciones iniciales, tales como posiciones, velocidades, y estados neuronales y, entonces, en cierto punto, el agente de la parte superior se sustituye por los movimientos registrados. Por lo tanto, los agentes necesitan discriminar las dos condiciones a trav´es de la interacci´on en curso, mientras que de alguna manera se explota la presencia de ruido. Esta forma de modelar el movimiento reproduce las condiciones an´alogas de la doble pantalla de televisi´on (Murray y Trevarthen., 1985[32]) y los experimentos de cruce perceptual (Auvray et al., 2009[5]). En este trabajo, s´olo los agentes inferiores fueron desarrollados para discriminar las interacciones en vivo de las grabadas. Esto significa que cada poblaci´on tiene una funci´on de adecuaci´on diferente (Ver figura 2.6). La poblaci´on de los agentes de la parte inferior es evaluada por ambos factores clave explicados anteriormente, mientras que solo se aplica el primer factor a los agentes de la parte superior. Con el fin de medir cu´antas veces un agente no se cruza con la grabaci´on durante una prueba, los tiempos m´aximos de cruce se establecieron arbitrariamente a 20 (un n´umero estimado en ejecuciones piloto) y de no-cruce se cuentan restando los tiempos de cruce del mismo. 16 Figura 2.6: Funciones fitness o de adecuaci´on para llegar a obtener la CTRNN ´optima para cada poblaci´on. [Extra´ıdo de Lenay y Stewart, 2012[26]] d) Resultados Los agentes evolucionados adquieren con ´exito la capacidad de discriminar entre las dos condiciones clave. Aqu´ı se muestra uno de dichos pares de agentes en detalle en un intento de sacar algunas conclusiones generales. La figura 2.7 muestra las trayectorias de ambos agentes bajo la interacci´on en vivo y la trayectoria del agente de la parte inferior cuando interact´ua con el movimiento grabado del agente de la parte superior (interacci´on unilateral); las diferencias de posici´on entre agentes superior e inferior se muestran a la derecha. La coordinaci´on de cruce se establece mientras que los dos agentes se mueven en una direcci´on y controlan sus aumentos y disminuciones de velocidad para cruzarse entre s´ı, sin perderse de vista el uno al otro. Bajo la condici´on de la interacci´on unilateral, se observa la ca´ıda de la coordinaci´on. Aunque no existe una gran diferencia en el comienzo de la interacci´on, con el tiempo el agente de la parte inferior se aleja de los movimientos grabados. Como la interacci´on unilateral comienza de la misma manera que la interacci´on en vivo, es decir, ambas condiciones tienen los mismos estados internos y f´ısicos en el momento de la conmutaci´on, una distorsi´on de la interacci´on en curso por la acumulaci´on de ruido sensorial debe causar la diferencia de comportamientos. Figura 2.7: Trayectorias de los agentes debidas a las interacciones en vivo y unilateral. La l´ıneas continuas delgada (agente de la parte superior) y gruesa (agente de la parte inferior) muestran los resultados de los comportamientos coordinados bajo la interacci´on en vivo. La l´ınea discontinua muestra la trayectoria del agente inferior al interactuar con la repetici´on de la l´ınea continua delgada (agente de la parte superior).(izquierda) La diferencia entre las dos trayectorias en cada condici´on. Cuando la l´ınea cruza 0 significa que dos agentes se cruzan entre s´ı.(derecha) [Extra´ıdo de Iizuka y Di Paolo, 2007[25]] 17 Estabilidad de ruido Sin ruido en la configuraci´on actual, no hay forma de saber si la pareja es reactiva o no reactiva. En otras palabras, el agente de la parte inferior necesita explotar el efecto del ruido para lograr la tarea. La figura 2.8 muestra el efecto del ruido en comportamientos coordinados. La coordinaci´on establecida entre dos agentes adaptativos se puede mantener sin ser destruida por el aumento de ruido. Aunque el ruido m´as fuerte rompe m´as la coordinaci´on, la coordinaci´on muestra una robustez frente a perturbaciones de ruido. Sin embargo, si el agente de la parte superior se sustituye por la grabaci´on no reactiva, la coordinaci´on no se establece m´as. Esto significa que el agente de la parte inferior explota la presencia de ruido para detectar que el compa˜nero no es reactivo y evitarlo. A pesar del hecho de que los comportamientos del agente de la parte superior son id´enticos en movimiento bajo las interacciones en vivo y unilaterales, el agente de la parte inferior no se coordina con la grabaci´on. Esto significa que s´olo las din´amicas mutuas de acoplado pueden mantener la coordinaci´on, mientras se suprimen las perturbaciones inducidas por el ruido sensorial. Figura 2.8: El n´umero promedio de cruces que los agentes evolucionados contra la intensidad de ruido que se investiga a intervalos de 0,01. Para calcular las medias, se utilizaron 100 pruebas para cada intensidad de ruido. La intensidad de ruido durante la evoluci´on es 0,05. [Extra´ıdo de Iizuka y Di Paolo, 2007[25]] 18 2.4. Extensiones y Modelos del Paradigma de cruce perceptual El estudio de Auvray et al. (2009)[5] ha tenido una gran influencia en diferentes ´areas de investigaci´on. Debido a su simplicidad, el paradigma de cruce perceptual sirve como ejemplo ilustrativo de la importancia de la din´amicas de interacci´on en l´ınea. En la tabla 2.2 se enumera y resume los estudios m´as importantes relacionados con el cruce perceptual. Tabla 2.2: Resumen de los estudios experimentales y de modelado m´as importantes de cruce perceptual. [Extra´ıdo de Auvray y Rohde, 2012[4]] Versi´on bidimensional del experimento original por Lenay et al. (2011)[27]. Diez parejas de participantes fueron colocadas en un espacio virtual de dos dimensiones. Se obtuvieron resultados similares al original: identificaci´on exitosa del contrario en t´erminos de porcentaje de clicks y distinci´on correcta debida a la frecuencia de estimulaci´on de cada fuente. Lenay et al. (2011)[27] se˜nalan que, mientras que los participantes exploran todo el espacio en busca unos de otros, una vez establecido el contacto, se vuelve a interacciones oscilatorias unidimensionales. Los patrones de comportamiento observado en los agentes rob´oticos, obtenidos por simulaciones de la tarea (Rohde y Di Paolo, 2008[37]; Rohde, 2010[36]; Lenay et al, 2011[27]), se ensayaron frente a los datos humanos. Hay evidencia del papel del escaneo oscilatorio para relocalizar al otro despu´es de perder contacto. Se sugiere la imposibilidad de predecir con precisi´on la ubicaci´on del contrario a pesar de la interacci´on coordinada, lo que puede explicar el comportamiento al hacer click(Auvray et al., 2009)[5]. No queda claro si la reducci´on de movimiento en una dimensi´on est´a relacionada con la anatom´ıa del brazo humano. 19 Variaci´on del paradigma por Iizuka et al. (2009[24],2012a[22]). Prob´o emp´ıricamente lo estudiado por simulaciones en anteriores estudios (Iizuka y Di Paolo de 2007[25] y Di Paolo et al, 2008[11]), la detecci´on de agentes en un entorno, donde la coordinaci´on unilateral (De Jaegher, 2009[10]) es una posibilidad te´orica. Introdujo un importante cambio en el paradigma original, en lugar de colocar simult´aneamente a la persona y su sombra en el mundo virtual, las pruebas fueron aleatorizadas para exponer a los participantes a una interacci´on en vivo (persona contra persona) o a una grabaci´on de otro participante en un ensayo anterior. Los participantes ten´ıan que decidir si hab´ıan percibido que la interacci´on era en vivo o no. Todos los sujetos empezaban a explorar y oscilar alrededor de las entidades encontradas de ambos tipos. Despu´es de s´olo unas pocas decenas de ensayos, los participantes desarrollaron un comportamiento de cambio de turno como una estrategia de sondeo activo. La diferencia importante con el paradigma de cruce perceptual de Auvray et al. (2009)[5] es que el procedimiento utilizado en este experimento aporta una soluci´on de coordinaci´on unilateral te´oricamente posible, explica el paradigma del doble monitor de TV de Murray y Trevarthen (1985)[32] m´as fielmente en un entorno virtual m´ınimo. Auvray et al. (2009)[5] centraba su atenci´on en el tipo de entornos y comportamientos que llevan a la coordinaci´on social, mientras que Iizuka et al. (2009[24], 2012a[22]) se centr´o en c´omo un individuo puede modular la din´amica de interacci´on para averiguar si una interacci´on es en vivo o no. Variante del paradigma de cruce perceptual por Iizuka et al. (2012b)[23]. Parejas de participantes se enfrentaban a diferentes est´ımulos visuales (formas) y ten´ıan que decidir despu´es de 30 segundos de cruce perceptual si ve´ıan la misma forma o una diferente. Con la informaci´on proporcionada, los participantes aprendieron no s´olo a esperar su turno en la interacci´on, sino tambi´en a acordar patrones caracter´ısticos de movimiento para representar la forma que pod´ıan ver. Lo particularmente interesante es que el movimiento oscilatorio se utiliza para localizar al contrario, comunicarse y negociar un vocabulario com´un. Todas estas actividades son procesos funcionales diferenciados, sin embargo, todos ellos se producen simult´aneamente Variante del paradigma original de Lenay y Stewart (2012)[26]. Evaluaron el grado en el que los participantes son capaces de reconocer expl´ıcitamente a su pareja. Los participantes recib´ıan informaci´on sonora en lugar de t´actil, cada sonido se asoci´o con uno de los tres tipos de objetos (contrario, sombra y fijo) del experimento original. Diez parejas de participantes fueron probados en 4 sesiones y la correspondencia sonido-entidad cambiaba en cada sesi´on. En las sesiones 1 y 2, el objeto m´ovil se encuentra a una distancia fija del contrario y en las sesiones 3 y 4, corresponde a las grabaciones de la trayectoria del contrario durante la sesi´on 2. Al final de cada sesi´on, se ped´ıa a los participantes asignar los tonos a los distintos tipos de entidades. Los resultados mostraban que el objeto fijo se reconoc´ıa f´acilmente. En cuanto a la diferenciaci´on entre entes m´oviles: en las sesiones 3 y 4, los participantes los distingu´ıan perfectamente; en las sesiones 1 y 2 solo acertaban en una de las sesiones. Se pudo observar una estrategia com´un para resolver la tarea. Los participantes identificaban primero el sonido correspondiente al objeto fijo, luego buscaban a su oponente, tratando de mantenerse en contacto con ´el, y finalmente, verificaban su clasificaci´on buscando el objeto m´ovil. Este cambio en la estrategia respecto al original indica que el reconocimiento consciente requiere de la modulaci´on de las din´amicas de cruce perceptual emergentes de la b´usqueda mutua (Iizuka et al., 2009[24] y 2012a[22]). Tambi´en se observ´o una mayor dificultad en discriminar la coordinaci´on unilateral de una interacci´on previa, en lugar de a una interacci´on en vivo, de acuerdo con los resultados de Iizuka et al. (2009[24], 2012a[22]). 20 Otra variaci´on del paradigma de cruce perceptual de Lenay y Stewart (2012)[26]. Se investig´o si los participantes son capaces de ajustar sus acoplamientos sensomotores para facilitar el cruce perceptual. En esta variaci´on del paradigma, los participantes pudieron ajustar la distancia entre su campo receptivo y su representaci´on (perceptible por contrincante). La distancia pod´ıa ser ajustada usando clicks de rat´on durante el cruce perceptual. Si la discrepancia es muy grande, se espera que la coordinaci´on no se estabilice. La tarea de los participantes fue ajustar dicha distancia para disminuir cualquier desviaci´on experimentada y estabilizar el cruce perceptual. Se encontr´o que, utilizando la din´amica de interacci´on como una se˜nal de realimentaci´on, los participantes fueron capaces de disminuir la discrepancia entre sus par´ametros de distancia y lograr una interacci´on m´as suave. Investigaci´on del paradigma de cruce perceptual en autistas de alto funcionamiento (HFAs) por Timmermans et al. (2011)[41]. Su objetivo fue determinar el nivel en el cual los HFAs tienen disminuidas las habilidades sociales. Algunos cient´ıficos afirman que los autistas tienen problemas con los aspectos autom´aticos de la cognici´on social (McIntosh et al., 2006[29]), otros no encuentran alteraci´on en sus facultades cognitivas que involucran la cognici´on social impl´ıcita, como en la representaci´on de acciones (Sebanz et al., 2005[38]) o el aprendizaje impl´ıcito (Brown et al., 2010[9]). Mediante el estudio de los HFAs en el paradigma de cruce perceptual, es posible comprobar si las personas autistas tienen dificultades en la coordinaci´on de las interacciones en l´ınea, o su percepci´on consciente de tales interacciones. Quince parejas de participantes fueron probadas en el paradigma de cruce perceptual; en ocho de estas parejas, un componente de la pareja de interacci´on era un HFA, en las otras siete no. No hubo diferencias significativas en el comportamiento motor o los patrones de coordinaci´on entre los dos grupos. Por tanto, los HFAs no parecen tener disminuidos los niveles de interacci´on social que se requieren para la coordinaci´on en el paradigma de cruce perceptual. Investigaci´on en el campo del dise˜no de Mart´ı (2010)[28]. Se inspir´o en el paradigma de cruce perceptual para construir el robot compa˜nero Iromec desarrollado con el prop´osito de colaborar con ni˜nos con diferentes discapacidades. El robot sigue a un ni˜no a una distancia fija tomando la misma trayectoria, ritmo y velocidad que el ni˜no, si otra persona se acerca m´as al robot, este comienza a seguirle hasta que el ni˜no se acerque de nuevo a ´el. El autor prob´o un escenario con un ni˜no de 9 a˜nos de edad con una discapacidad cognitiva leve implicando dificultades de atenci´on y retrasos en el aprendizaje. Analizando las grabaciones de v´ıdeo, los maestros del ni˜no estuvieron de acuerdo en que el ni˜no era muy capaz de sostener la actividad a trav´es de una serie de tareas, lo que sugiere que su capacidad de enfocar la atenci´on era mejor de lo habitual. El autor muestra c´omo las lecciones aprendidas de la experiencia de cruce perceptual se pueden utilizar en el dise˜no de artefactos tecnol´ogicos para mejorar la motivaci´on para actuar, la atenci´on a la movilidad, la coordinaci´on y la interacci´on interpersonal b´asica. Experimentos de cruce perceptual para investigar las interacciones sociales entre palomas (Ware, 2011[42]). Utiliz´o un m´etodo similar al de Murray y Trevarthen (1985)[32], un aparato teleprompter de doble circuito cerrado permit´ıa a dos p´ajaros situados en habitaciones diferentes interactuar en tiempo real a trav´es de v´ıdeo. Se observaban comportamientos de cortejo, indicado por el hecho de que las palomas caminaban en c´ırculos. Se compar´o el comportamiento de cortejo de 12 palomas (seis machos y seis hembras) cuando ve´ıan un v´ıdeo en tiempo real de cada una de sus parejas y cuando se trataba de una grabaci´on anterior con los mismos participantes. Los resultados revelaron como la interacci´on en vivo beneficia el comportamiento de cortejo. El comportamiento de caminar en c´ırculos de las palomas tambi´en se redujo cuando se introduc´ıa un retraso en la interacci´on en tiempo real. No hubo efecto del ´angulo de visi´on. Los resultados de Ware revelan que el comportamiento de cortejo de las palomas no se basa ´unicamente en las se˜nales visuales, sino que tambi´en est´a influenciado por la sensibilidad a las contingencias sociales existentes entre se˜nales. 21 1. Primero se pasa por la p´agina inicial donde el usuario introduce su nombre de jugador. En la figura 4.2 se puede observar la p´agina inicial de la aplicaci´on. Figura 4.2: Capturas de index.html 2. Dependiendo del nombre de usuario introducido en la anterior p´agina se avanzar´a a una p´agina u otra. a) Si el nombre de usuario es el del administrador se accede a la p´agina de control del comportamiento de la aplicaci´on. Desde esta pantalla se pueden consultar y modificar los datos de configuraci´on de la aplicaci´on almacenados en el fichero configuration.json1 y habilitar/deshabilitar una barrera que impide el paso de los usuarios normales a la p´agina juego.html. En la tabla 4.1 se ve una lista de los par´ametros de configuraci´on con su descripci´on y en la figura 4.3 se muestra una captura de la p´agina. Tabla 4.1: Tabla con los par´ametros de configuraci´on y su descripci´on. b) Si es otro nombre, se pasa a la p´agina de explicaci´on, donde se informa al usuario acerca del experimento que va a realizar a continuaci´on. Si el administrador a deshabilitado la barrera y el n´umero de usuarios para el experimento es el definido, se avanzar´a a la p´agina de juego. En la figura 4.3 se observa la p´agina de explicaci´on. 1Para ver la estructura que tiene configuration.json consultar la secci´on D.1 del ap´endice D de los anexos. 28 Figura 4.3: Captura de adminBarrier.html (izquierda) y de explicacion.html (derecha) 3. En la p´agina de juego se desarrollan los experimentos y se recoge la informaci´on pertinente de los mismos. La p´agina pasa por distintos estados: a) El usuario espera a que todos los jugadores est´en listos (Ver figura 4.4). b) Se juega la ronda del experimento durante los segundos marcados por el cron´ometro c) Seg´un el modo de juego, se contestar´a a un cuestionario o simplemente se continua a la siguiente ronda, volviendo al estado de espera. Cuando se han jugado el n´umero de rondas definidas se avanza a la siguiente p´agina. 4. La siguiente p´agina es la del ranking, un incentivo para que los jugadores se esfuercen durante los experimentos. Seg´un el modo de juego en el que nos encontremos se visualizar´a un ranking u otro (Ver figura 4.4). El administrador puede programar que se de una segunda vuelta de rondas por lo que se volver´ıa a la p´agina de juego o bien terminar en la primera vuelta y avanzar a la p´agina de cuestionario. Figura 4.4: Captura de juego.html en espera (izquierda) y de ranking.jsp en modo normal (derecha) 5. Tras ranking se accede a la p´agina de cuestionario (Ver figura 4.5 ), cuyo objetivo es recoger informaci´on de la experiencia de utilizar la aplicaci´on por parte de los usuarios y de esa manera ajustar tiempos de ronda, corregir posibles errores, etc. 6. La ´ultima p´agina es la de despedida (Ver figura 4.5), en ella se muestra un mensaje de fin de partida y se tiene la posibilidad de volver a la p´agina inicial presionado un bot´on. 29 Figura 4.5: Captura de cuestionario.html (izquierda) y de game over.html (derecha) 4.2. Descripci´on elementos de juego.html La p´agina juego.html tiene dos zonas bien diferenciadas, la zona de juego y la zona de respuesta o paso de ronda. La zona de juego tiene los cinco elementos que se pueden ver en la figura 4.6. 1. Informaci´on sobre la ronda en la que nos encontramos. 2. Explicaci´on de c´omo se debe actuar en el momento actual. 3. Un cron´ometro. Marca el tiempo de ejecuci´on de una ronda o experimento. 4. Seg´un el estado de la ronda, puede aparecer:  La imagen de un rat´on indicando de forma gr´afica el movimiento a realizar durante el juego.  Una cuenta atr´as, previa a la ronda (3, 2, 1, YA!)  Un marcador de colisiones activas. 5. Una l´ınea de 800 p´ıxeles de longitud y un cuadrado 50 p´ıxeles de lado. La l´ınea representa el espacio unidimensional de experimento y el cuadrado el campo receptor del sujeto. Figura 4.6: Partes de la zona de juego. La zona de respuesta o paso a la siguiente ronda no es visible en todo momento, solo se hace visible al terminar de jugar una ronda por completo. Como se observa en la figura 4.7, dependiendo del modo de juego en que nos encontremos aparecer´a un contenido u otro.  Zona de respuesta a la pregunta de si ha interactuado con una persona o una m´aquina, seg´un su respuesta aparece un aviso informativo de acierto o fallo.  Zona de paso, se muestra un mensaje que informa al usuario de que se han guardado los datos correctamente y que puede continuar presionando el bot´on correspondiente. 30 Figura 4.7: Zona de respuesta (arriba) y zona de paso (abajo) 4.3. Descripci´on de una ronda y estados de la aplicaci´on cliente Descripci´on de una ronda Una vez est´an todos los sujetos humanos listos, aparece una cuenta atr´as (3, 2, 1, YA!) que marca el comienzo del experimento de cruce perceptual. La pantalla pasa a negro, aparece el marcador de colisiones a 0 y el cron´ometro se pone en marcha. A partir de este momento el usuario puede comenzar a mover su cuadrado receptor durante el resto de la ronda. Cuando se produce una colisi´on con el marcador de un oponente, el cual no es visible, se produce un est´ımulo visual (el cuadrado del usuario cambia de color fugazmente y el marcador de colisiones se incrementa) y otro auditivo (Efecto Doppler). El sonido se reproduce cuando las superficies de los cuadrados se tocan, alcanzado el m´aximo volumen de audio en una colisi´on perfecta y que va disminuyendo como se alejan, en el momento en que dejan de tocarse el sonido desaparece por completo. Una vez termina el tiempo de ronda, el usuario ya no puede mover el cuadrado, en la zona inferior seg´un el modo de juego2en que nos encontremos aparece: Modo normal: Un cuestionario que el usuario debe responder seg´un piense que ha interactuado con una persona o una m´aquina. Se confirma la respuesta con un mensaje de acierto o fallo. Modo m´ultiple: Un aviso de fin de ronda y un bot´on para continuar Antes de comenzar la siguiente ronda o terminar si no hay m´as rondas, la informaci´on de la ronda actual se almacena en el servidor. Estados de la aplicaci´on cliente En la figura 4.8 se puede ver la serie de estados por la que pasa el cliente durante el transcurso de cada ronda y una breve explicaci´on de los mismos. Figura 4.8: Ciclo de estados por los que pasa la aplicaci´on cliente. 2La explicaci´on de los modos de juego se encuentra en la secci´on 4.5 de este cap´ıtulo. 31 4.4. Arquitectura cliente-servidor La funci´on principal del sistema, est´a construida sobre una arquitectura de tipo cliente-servidor (WebSockets). En la figura 4.9 puede observarse dos esquemas simplificados a modo de ejemplo de las conexiones y relaciones que se crean en la arquitectura de la aplicaci´on seg´un el modo de juego. Se siguen estos pasos para montar la estructura: 1. Un cliente se conecta al servidor. 2. Hace que se genere un objeto de la clase GameConnection, que representa al cliente en el servidor. 3. El servidor, de ser necesario, genera los bots u objetos BotPlayer. 4. Estos, a su vez, crean objetos BotThread que ejecutan el bucle principal de bot en un hilo de ejecuci´on paralelo para no bloquear la aplicaci´on. Figura 4.9: Arquitectura ronda Persona vs Persona (izquierda) y Arquitectura ronda Persona vs Bot (derecha). 4.5. Modos de juego La aplicaci´on soporta tres modos de juego, que permiten reproducir experimentos originales y crear otros nuevos: normal, m´ultiple (tiempo) y m´ultiple (p´ıxel). 1. El modo normal permite representar el experimento de Iizuka y Di Paolo (2007)[25] y el de Iizuka et al.(2009[24],2012a[22]). Una ronda de este tipo es de uno contra uno, bien “persona” vs“persona”o “persona vs bot”. Durante el tiempo delimitado el jugador mover´a su cuadrado receptor interactuando con el de su adversario. Una vez finalizado ese tiempo el jugador debe responder a la cuesti´on de si ha interactuado con una m´aquina o una persona. 2. El modo m´ultiple con retardo por tiempo se corresponde a un combinaci´on del experimento original de Auvray et al.(2009)[5] a˜nadi´endole la dimensi´on temporal del de Iizuka y Di Paolo (2007)[25]. En una ronda de este modo, cada sujeto (persona) se enfrenta a otro sujeto (persona), la sombra del contrincante con un retardo en milisegundos y un valor espacial fijo. Durante el transcurso de la ronda el jugador puede mover el cuadrado para interactuar con el resto de jugadores y hacer click para indicar que piensa que la ´ultima interacci´on ha sido con el contrario-persona (hit), contra m´as aciertos mejor. Al finalizar la ronda la informaci´on pertinente es almacenada y el jugador puede avanzar a la siguiente ronda o terminar la vuelta. 32 3. El modo m´ultiple con retardo por longitud se corresponde con el experimento original de Auvray et al.(2009)[5]. Es igual al anterior modo m´ultiple salvo que cada sujeto (persona) se enfrenta a otro sujeto (persona), la sombra del contrincante con una distancia en p´ıxeles y un valor espacial fijo distinto al asignado a su contrincante. 4.6. Modos de un bot Los diferentes tipos de bot implementados para el proyecto son los siguientes: SIMPLE: Env´ıa mensajes de posicionamiento del cuadrado de forma incremental cada segundo. Se usaba solo en modo normal. RANDOMSIMPLE: Env´ıa mensajes de posicionamiento con un valor aleatorio entre 0 y 800 cada medio segundo. Se usa solo en modo normal. SHADOW: Repite la traza de posiciones de un sujeto persona jugada en una ronda anterior. Se usa solo en modo normal. DELAYEDSHADOW: Repite la traza de posiciones de la persona con la que se est´a jugando la ronda actual, con un retraso en milisegundos. Se usa en modo normal y m´ultiple con retraso por tiempo. COMPLEX: Por defecto cuando el bot recibe mensajes del jugador persona se acerca a su posici´on, mientras no recibe mensajes se aleja. Las pol´ıticas de acercamiento o alejamiento pueden ser reprogramadas como interese. Se usa solo en modo normal. PIXELSHADOW: Retransmite la traza de posiciones de la persona con la que se est´a jugando la ronda actual, menos una distancia en p´ıxeles. Se usa solo en modo m´ultiple con retraso por distancia en p´ıxeles. 4.7. Errores tratados gr´aficamente Se controlan una serie de posibles eventualidades que pueden terminar en error. Si se llega a producir un fallo, se muestra al usuario por pantalla una informaci´on descriptiva del problema y, si existe, una forma de recuperarse. En caso de una ca´ıda del servidor mientras se est´a en la pantalla de juego se muestra el error de la captura superior de la figura 4.10, reescribiendo el c´odigo HTML de la misma p´agina. Si se produce el intento de conexi´on con el servidor de un cliente con el mismo identificador que otro ya conectado, se rechaza. En la captura central de la figura 4.10 puede observarse el mensaje que se mostrar´ıa por pantalla. Si mientras dos jugadores humanos enfrentados juegan su ronda, uno de ellos pierde la conexi´on sin haber terminado la cuenta atr´as del cron´ometro, al jugador todav´ıa conectado se le informa del suceso y se le da la oportunidad de repetir la ronda, como se muestra en la captura inferior de la figura 4.10. Para una informaci´on ampliada de la aplicaci´on principal consultar el ap´endice B, en especial la subsecci´on B.1.6. Tambi´en resulta interesante las tablas comparativas del ap´endice F. 33 Figura 4.10: Error producido al caerse el servidor (arriba). Error producido al intentar conectarse con un identificador de conexi´on existente (centro). Error producido al caerse el jugador contrario (abajo). 4.8. Visor de gr´aficas Como complemento a la aplicaci´on principal del proyecto he desarrollado un conjunto de visores de gr´aficas que permiten analizar los datos recogidos durante los experimentos. Para construir estos interfaces he utilizado la herramienta software EJS (Easy Java Simulations) dise˜nada para la creaci´on de simulaciones discretas por computador. A partir de los elementos gr´aficos ofrecidos por el programa para confeccionar interfaces de usuario, he construido los m´as apropiados para el estudio de resultados de los tres modos implementados en este proyecto. Adem´as EJS permite importar tus propias clases Java y a˜nadir c´odigo complementario implementado por uno mismo, y de esa manera acceder a la informaci´on deseada. En la figura 4.11 puede verse el visor construido para el estudio de trazas almacenadas durante el modo normal de juego, con una gr´afica cargada. Figura 4.11: Visor gr´aficas modo normal Para leer una descripci´on m´as detallada de los visores y observar ejemplos de gr´aficas acudir al ap´endice C de los anexos. 34 Cap´ıtulo 5 Resultados En este cap´ıtulo se recogen todos aquellos aspectos del proyecto que tienen que ver con la recopilaci´on de informaci´on ´util acumulada durante el transcurso del mismo, eso incluye informaci´on de rondas, cuestionarios de uso y toma de medidas de los diferentes modos de trabajo. Tiene cinco secciones bien diferenciadas: en la primera de ellas se describe la informaci´on que se almacena de cada ronda, teniendo en cuenta los diferentes modos de juego y la estructura de la informaci´on de uso de la aplicaci´on recogida; en la segunda una descripci´on de los experimentos realizados para toma de medidas de prestaciones; en la tercera una descripci´on m´as en concreto de los datos del modo normal; en la cuarta del modo m´ultiple tanto con retardo en milisegundos, como con distancia en p´ıxeles; en la quinta una comparativa temporal con el experimento de Iizuka y Di Paolo (2007)[25]. 5.1. Informaci´on almacenada Despu´es de jugar una ronda, cada jugador env´ıa al servidor un mensaje con informaci´on recogida en dicha ronda. El servidor va almacenado los diferentes mensajes de una vuelta completa en un fichero de texto, que estar´a formado por l´ıneas de esos mensajes, el nombre de este fichero est´a formado por el nombre del jugador del que se recoge informaci´on concatenado con la fecha y hora en el instante de conectarse al servidor, adem´as en modo m´ultiple tiene el prefijo “MT”, en el caso de retardo en milisegundos, o “MP”, en el caso de distancia en p´ıxeles. Los principales campos de informaci´on que se guardan identifican la ronda jugada, par´ametros de la misma, al jugador del que se guarda la informaci´on, la traza de sus movimientos y al oponente u oponentes. Seg´un el modo de juego en el que se desarrolla una ronda se almacenar´a un tipo de mensaje de informaci´on de ronda u otro, en modo normal ser´a de tipo roundInfo y en modo m´ultiple roundMMInfo.1 La principal diferencia entre ambas estructuras es que en modo normal la partida es de uno contra uno, bien entre dos personas o entre una persona y un bot, mientras que en modo m´ultiple cada jugador persona se enfrenta a tres oponentes, una persona, su sombra, bien con retardo en milisegundos, bien con distancia en p´ıxeles y un valor fijo, por ello difieren en los campos relacionados con este hecho. Adem´as, en el caso normal aparecen campos relacionados con la pregunta final que el m´ultiple no posee, por el contrario en el modo m´ultiple aparece un campo en relaci´on con los clicks realizados por el jugador que no contiene el modo normal. La principal diferencia entre los modos m´ultiples es el tipo de bot sombra, pudiendo ser DELAYEDSHADOW o PIXELSHADOW2. 1Para m´as informaci´on de este tipo de mensajes consultar la secci´on D.5 del ap´endice D de los anexos. 2Para ver una descripci´on de DELAYEDSHADOW y PIXELSHADOW acudir a la subsecci´onB.1.5 del ap´endice B. 35 Durante el desarrollo de la aplicaci´on se han cambiado campos de estas trazas para adecuarlos a nuevas funcionalidades que han aparecido, el caso m´as destacado es el de inclusi´on de informaci´on necesaria para poder reconstruir las trazas de los jugadores oponentes. Esta informaci´on es utilizada por los visores creados con EJS (Easy Java Simulations)3, introducidos en la secci´on 4.8 del cap´ıtulo 4, para construir, de forma gr´afica, las trazas de sus movimientos. Una de las p´aginas que componen la aplicaci´on es ”cuestionario.html”, esta recoge informaci´on de los usuarios tras completar por completo el experimento programado. Tiene tres preguntas: escribe brevemente cual ha sido tu estrategia, en caso de haber acertado que el jugador oponente era una m´aquina o una persona ¿En qu´e te has fijado para descubrirlo? y en caso de haber fallado que el jugador oponente era una m´aquina o una persona ¿En qu´e te has fijado para intentar descubrirlo?, esto permite tener feedback con los usuarios, observar estrategias que siguen, modificar los par´ametros de la aplicaci´on que sean necesarios para conseguir una mejor experiencia en los experimentos, etc. Esta informaci´on se guarda en ficheros de texto, cuyo nombre esta compuesto por una“C”concatenada con el identificador de conexi´on del usuario y la fecha y la hora de conexi´on con el servidor. 5.2. Descripci´on medici´on de prestaciones Para medir las prestaciones de la aplicaci´on se realiz´o una serie de pruebas sobre la misma planteando diferentes escenarios de juego4. Se insert´o instrumentaci´on en el c´odigo para que se pudiera obtener tras una ronda el n´umero de mensajes recibidos y enviados y un tiempo de ronda. Los datos medidos siempre hacen referencia a la partida y trazas de los jugadores persona. Luego en modo off-line con un programa habilitado al caso se hizo un an´alisis de las trazas de las partidas, midiendo las diferencias de tiempo entre un mensaje enviado y el siguiente, para calcular la velocidad m´axima media de env´ıo, comprobando la sensibilidad del escuchador de captura de movimiento del rat´on, ya que, por cada captura se env´ıa un mensaje. Cada prueba realizada constaba de 10 rondas de 10 segundos cada una. Durante una partida se segu´ıa una estrategia por la cual se mov´ıa el rat´on de un lado a otro los m´as r´apido posible, adem´as de hacer clicks en modo m´ultiple, para que los datos recogidos fueran lo m´as fiables posible a la hora de medir los l´ımites de la tecnolog´ıa utilizada para implementar la aplicaci´on. En modo normal se realiz´o un experimento persona contra bot, por cada tipo de bot y uno entre dos personas, en el caso del bot DELAYEDSHADOW, 5 pruebas, cambiando el valor del retardo. En modo m´ultiple, para el caso de retardo en tiempo, se hicieron 5 experimentos variando el retraso en milisegundos de la sombra. Para el caso de distancia en p´ıxeles solo una prueba, ya que cambiar el valor de la distancia no altera los tiempos tomados como en el caso de retardo por tiempo. De cada experimento se obtuvo 3 datos de inter´es: la media de mensajes enviados por segundo, la media de mensajes recibidos por segundo y la diferencia media total entre mensajes enviados. Durante la toma de medidas, se observ´o que la primera ronda de todos los experimentos tiene una tasa de mensajes enviados mucho mayor que el resto de rondas, achacable a que en el cliente en primera instancia no hay memoria reservada para las estructuras de datos que almacenan la informaci´on de una ronda y dem´as datos auxiliares, que se van creando en esta primera partida. Por ello, se consider´o el primer dato de cada experimento como un dato at´ıpico que podr´ıa mejorar las prestaciones temporales de la aplicaci´on notablemente, no se ha incluido en las medias calculadas para que los datos sean m´as fidedignos y se centren en el grueso de informaci´on m´as representativa, ya que en las siguientes rondas de los experimentos los tiempos no difieren tanto unos de otros. 3Para leer una descripci´on m´as amplia de los visores implementados y ejemplos de las gr´aficas ir al ap´endice C 4Para ver en que consisten los experimentos con m´as detalle, acudir a la secci´on E.1 del ap´endice E, donde puede verse un resumen esquematizado de los mismos. 36 Para una descripci´on m´as en detalle de la medici´on de prestaciones acudir a las secciones E.2, E.3 y E.4 del ap´endice E de los anexos. 5.3. Experimento modo normal En esta secci´on se describe la informaci´on recogida en este modo de juego. En primer lugar la obtenida por las visitas realizadas que pudieron probar la aplicaci´on y en segundo la acumulada por la medici´on de prestaciones descrita en la secci´on 5.2. 5.3.1. Informaci´on de las visitas En febrero de este a˜no se realizaron una serie de visitas, al campus R´ıo Ebro, por parte de alumnos de educaci´on secundaria que pudieron probar durante parte de su visita el modo normal de la versi´on de la aplicaci´on desarrollada hasta ese momento. Estas visitas ayudaron mucho a la hora de testear la aplicaci´on, se corrigieron errores seg´un se iban planteando, se a˜nadieron campos a la traza de datos que se almacenaba, se implemento la p´agina de administrador, para tener control de la aplicaci´on sin modificar manualmente el fichero configuration.json5y de los propios jugadores creando una barrera de acceso a la p´agina juego.html y surgi´o la idea del ranking y de una cuenta atr´as previa a cada ronda para hacer m´as atractiva la aplicaci´on. Se cre´o la p´agina de cuestionario para poder recoger informaci´on de primera mano del uso de la aplicaci´on que los usuarios, conocer sus estrategias, si el n´umero de rondas y el tiempo de duraci´on de cada una era el correcto, etc. Algunas de las estrategias que parecieron interesantes fueron: Quedarse quieto y analizar la rapidez y ritmo del sonido de las colisiones. Observar el n´umero de colisiones y si ten´ıan lugar en distintos sitios. Si hab´ıa poca colisiones en distinto lugar se trata de una m´aquina. Ir despacio y observar si los cambios son bruscos, en ese caso se trata de una m´aquina. Si ante mis movimientos el oponente cambia su comportamiento, es una persona. Para ver que bots6enga˜naban m´as a los jugadores se analizo las trazas obtenidas. Como puede observarse en la tabla 5.1, si bien no es muy grande el n´umero de rondas estudiadas, se puede distinguir que hay tipos de bot m´as f´aciles de detectar, como es el caso de los SHADOW, de lo que se puede deducir lo importante que resulta la sincronizaci´on entre jugadores y los cambios originados por comportamientos del oponente, ya que aunque se trata de la reproducci´on de la traza de una persona, al no estar sincronizada con el jugador persona de la ronda actual, su comportamiento no se adapta a los cambios, es siempre el mismo. A ra´ız de estos resultados y hablar con los usuarios se cambiaron las pol´ıticas del modo COMPLEX, para pasar de acercarse al receptor del jugador humano tanto cuando se mov´ıa como cuando se estaba quieto, a acercarse solo cuando se mueva y alejarse cuando este quieto. RANDOMSIMPLE SHADOW DELAYEDSHADOW COMPLEX % Aciertos 64,10 73,68 50 53,85 % Fallos 35,90 26,32 50 46,17 Tabla 5.1: Tabla porcentajes de acierto y fallo seg´un el tipo de bot. 5Para ver la estructura que tiene configuration.json consultar la secci´on D.1 del ap´endice D de los anexos. 6Para obtener informaci´on del comportamiento de cada bot acudir a la subsecci´on B.1.5 del ap´endice B de los anexos. 37 44 Parte II Anexos 45 Anexo A Tecnolog´ıa utilizada para el desarrollo de la aplicaci´on A.1. Conocimientos adquiridos y tecnolog´ıa usada en la aplicaci´on A la hora de analizar la tecnolog´ıa utilizada en la implementaci´on de esta aplicaci´on web se pueden distinguir dos partes bien diferenciadas: front-end yback-end. A.1.1. Front-end El front-end es la parte del software que interact´ua con los usuarios. En esta aplicaci´on, m´as en concreto, se refiere al programa cliente que ser´a interpretado por el navegador del usuario, cubriendo el aspecto visual de la p´agina web, respuesta gr´afica a eventos provocados por el usuario y todos los mecanismos de recolecci´on y gesti´on de la informaci´on introducida por el usuario al interactuar con la web, de dicha informaci´on se selecciona la ´util para el servidor y se le env´ıa. Los lenguajes utilizados para la implementaci´on del front-end son: 1. HTML5 (HyperText Markup Language, versi´on 5) 2. CSS (Cascading Style Sheets) 3. JavaScript HTML5 HTML5 es la quinta revisi´on importante del lenguaje b´asico de la World Wide Web, HTML, se trata de una herramienta potente para la construcci´on de p´aginas web. Destacan nuevas directivas respecto a la anterior versi´on como CANVAS o AUDIO para la manipulaci´on de objetos multimedia y directivas para manejar la Web Sem´antica (Web 3.0), como son HEADER o FOOTER, estas etiquetas permiten describir cual es el significado del contenido, no tienen impacto importante en la visualizaci´on, se orientan a buscadores. Se busca el firme objetivo de separar el contenido del aspecto visual de la web y un renovado ´enfasis en la importancia del scripting DOM (Document Object Model) para la gesti´on del comportamiento de la web. 47 CSS CSS es un lenguaje de hojas de estilos usado para describir el aspecto y formato de un documento escrito en lenguaje de marcas. La descripci´on de estilo puede ser adjuntada en el mismo documento HTML o como un documento separado, esta ´ultima opci´on permite reutilizar un mismo estilo para varias p´aginas. CSS da versatilidad a la hora de personalizar el estilo de las p´aginas web y subraya la idea aplicada en HTML5 de separar el aspecto del contenido. JavaScript JavaScript es un lenguaje de programaci´on interpretado, orientado a objetos, basado en prototipos, imperativo, d´ebilmente tipado y din´amico, que aporta la parte din´amica de la p´agina web, tanto en el apartado gr´afico como en el funcional. Se usa principalmente en la parte del cliente pero su uso tambi´en est´a comenzando a extenderse al lado del servidor, ejemplo de ello es el entorno de programaci´on en la capa del servidor Node.js, basado en JavaScript. En la aplicaci´on del proyecto juega un rol importante tanto en la gesti´on de la interacci´on del usuario con los objetos gr´aficos, como en la comunicaci´on entre el cliente y el servidor basada en la tecnolog´ıa WebSocket, la cual se describe m´as adelante. Como fue avanzando el desarrollo de la aplicaci´on descubr´ı la existencia de una biblioteca de JavaScript llamada jQuery, que permite facilitar el uso de JavaScript simplificando la manera de interactuar con los documentos HTML, manipular el ´arbol del DOM, manejar eventos, desarrollar animaciones y agregar interacci´on con la t´ecnica AJAX (Asynchronous JavaS- cript And XML) a p´aginas web. Lo que m´as ´util me ha resultado han sido sus selectores para acceder a los elementos del documento. En la tabla A.1 se observan ejemplos de la potencia de sus selectores. Selector jQuery Selecci´on significado $(’p:first’) Selecciona el primer ’<p>’ de la p´agina. $(’img[src$=.png]:first’ Selecciona el primer ’<img>’ de la p´agina que tiene un atributo src acabado en .png. $(’p:last’) Selecciona el ´ultimo ’<p>’ de la p´agina. $(’li:first-child’) Selecciona todos los ’<li>’ que son primeros hijos. $(’li:last-child’) Selecciona todos los ’<li>’ que son ´ultimos hijos. $(’li:only-child’) Selecciona todos los ’<li>’ que sean hijos ´unicos. $(’tr:nth-child(odd)’) Selecciona todos los ’<tr>’ que sean impares. $(’div:nth-child(3n)’) Selecciona cada tercer ’<div>’. $(’p[title^="H"]’) Selecciona todos los ’<p>’ cuyo atributo title comienza por H. Tabla A.1: Ejemplos de uso de selectores de jQuery Adem´as de simplificar el uso de JavaScript, jQuery aporta una capa de abstracci´on que hace que sea compatible con la mayor´ıa de navegadores. Cabe destacar que la aplicaci´on est´a desarrollada para que funcione de forma correcta en el navegador Mozilla Firefox, de tal manera, que no se garantiza que funcione adecuadamente en otros navegadores. El uso de jQuery en la aplicaci´on del proyecto es parcial, ya que descubr´ı la librer´ıa con la implementaci´on del cliente bastante avanzada, en desarrollos futuros me gustar´ıa completarla, de esta manera implementar´ıa de forma sencilla la portabilidad a otros navegadores. 48 A.1.2. Back-end El back-end es la parte del software que procesa la entrada de informaci´on enviada desde el front-end. En este caso incluye el servidor web y todos aquellos programas necesarios para la recepci´on de informaci´on proveniente del cliente y su tratamiento con la consiguiente respuesta al cliente o su almacenamiento para un estudio posterior de los datos. Para entender las decisiones tomadas en el lado del servidor se debe recalcar que el principal problema en el desarrollo de esta aplicaci´on era encontrar una tecnolog´ıa que nos permitiese establecer una v´ıa de comunicaci´on para transmitir informaci´on entre clientes en tiempo real, minimizando latencias y teniendo en cuenta la sincronizaci´on. Estudi´e varias posibilidades, las m´as adecuadas son WebSockets y RTC PeerConnection. WebSocket es una tecnolog´ıa que permite crear un canal de intercambio de informaci´on bidireccional y as´ıncrono entre el servidor y el cliente. Una vez establecida la conexi´on entre el cliente y el servidor el flujo de datos ser´a libre, no dependiente de peticiones repetitivas de servicio por parte del cliente al servidor (Tecnolog´ıa Pull). Las principales ventajas de WebSocket son: Mejora en la relaci´on entre datos ´utiles enviados y datos de cabecera frente al caso de HTTP. Por lo anterior disminuye la latencia. Soportado por la mayor´ıa de navegadores. Tasa de mensajes recibidos/enviados por el cliente muy alta, a´un estando el servidor de intermediario. Sus desventajas m´as importantes: No hay implementaci´on directa cliente-cliente de transacci´on de datos. De lo anterior se podr´ıa disminuir m´as la latencia. RTC PeerConnection es una tecnolog´ıa que permite crear un canal bidireccional“peer to peer”entre dos clientes. Soporta tanto v´ıdeo como sonido para implementar videoconferencia sin necesidad de intercambio de datos con el servidor. Sus principales ventajas son: Conexi´on directa entre clientes, sin pasar datos al servidor. Por lo anterior disminuye la latencia. Sincronizaci´on m´as f´acil de implementar Sus desventajas m´as importantes: Tecnolog´ıa joven, poca documentaci´on. Solo la soportan navegadores con plataforma base WebKit (Safari, Google Chrome,. . . ). Entre las dos opciones termine eligiendo WebSockets, ya que, siendo todav´ıa joven es la m´as veterana de ambas, ofreciendo una fiabilidad mayor que RTC PeerConnection¸ adem´as esta ´ultima solo funciona para navegadores con motor gr´afico WebKit. Teniendo en cuenta que los experimentos a realizar se plantean en un marco de red local, la importancia de la latencia que introduce entre clientes el servidor al hacer de intermediario del canal de comunicaci´on, pierde importancia. 49 El primer paso a seguir para establecer una canal entre el cliente y el servidor es el proceso conocido como WebSockets Handshake, por el cual el cliente env´ıa una petici´on de negociaci´on al servidor y aguarda una respuesta del mismo, que puede tanto aceptar como rechazar la propuesta. Este intercambio inicial de informaci´on se hace utilizando el protocolo HTTP (Hypertext Transfer Protocol), en este mensaje se est´a pidiendo un cambio a nivel de aplicaci´on del protocolo HTTP al WebSocket, mucho menos pesado, ya que la cabecera de HTTP es mucho mayor, introduce en la trama enviada m´as informaci´on no ´util (metadatos). Si el servidor acepta la petici´on, se constituye un canal de comunicaci´on bidireccional y full-duplex sobre un ´unico socket TCP, por lo que cliente y servidor pueden comenzar a enviarse de forma simult´anea y as´ıncrona informaci´on. En la figura puede verse un diagrama que representa este proceso. Figura A.1: Ejemplo de Handshake e intercambio de datos del protocolo WebSocket. [Extraido de http://marakana.com/bookshelf/html5 tutorial/web sockets.html] Como se ha descrito anteriormente la trama WebSocket es mucho m´as ligera, cada trama comienza con un byte 0x00 y termina con un byte 0x0F, entre ambos bytes se encuentra la informaci´on ´util en formato de codificaci´on UTF-8. Se pueden mandar tramas de datos tanto en texto como en binario, el caso de texto est´a soportado, sin embargo si se quisiera enviar informaci´on binaria, en la actualidad no esta soportado, habr´ıa que delegar tanto en el cliente como en el servidor la tarea de tratar dicha informaci´on. En la aplicaci´on del proyecto se env´ıa la informaci´on en modo texto, para ser m´as exactos en el formato para intercambio de datos JSON, el cual se define en un p´arrafo posterior. Para una mayor estudio acerca del protocolo WebSocket se deber acudir al RFC-6455 y para obtener informaci´on sobre la API del protocolo a http://www.w3.org/TR/2011/WD-websockets- 20110419/. JSON (JavaScript Object Notation) es un formato ligero para el intercambio de datos, subconjunto de la notaci´on literal de objetos de JavaScript que no requiere el uso de XML. El porque de la utilizaci´on de JSON frente a XML, un formato de serializaci´on de datos m´as extendido y veterano, es que JSON representa mejor la estructura de los datos y requiere menos codificaci´on y procesamiento. En la parte del cliente, gracias a JavaScript, la conversi´on de texto a objeto es inmediata y en la parte del servidor solo hace falta un objeto de clase Gson para hacer la conversi´on de texto a objeto y viceversa. 50 Una vez elegido el protocolo de comunicaci´on, hab´ıa que elegir el servidor a utilizar que soportase dicho protocolo. Dentro de las posibles implementaciones que investigu´e, me decant´e por aquellas implementadas en Java, ya que tengo m´as experiencia en el uso de este lenguaje de programaci´on, para ser m´as exactos estudie ejemplos de implementaci´on para servidores Tomcat, GlashFish y Jetty. Fuera de Java investigu´e Node.js, comentado en un punto anterior, lo que me daba la posibilidad de utilizar JavaScript en el lado del servidor, lo que habr´ıa dado m´as uniformidad al c´odigo, al utilizar menos lenguajes de programaci´on, pero con la complejidad del aprendizaje de los nuevos elementos a˜nadidos a la API de JavaScript. Finalmente para la aplicaci´on utilizo un servidor Tomcat a partir de la versi´on 3.2. Para cubrir la comunicaci´on cliente-servidor con la actividad principal de la aplicaci´on, la p´agina de juego, como se ha explicado con anterioridad, he utilizado WebSockets, para cubrir dicha comunicaci´on en tareas secundarias he usado una combinaci´on Java Servlets y JSP (Java Server Pages). Un Servlet es una clase en lenguaje Java usada para ampliar la funcionalidad de los servidores web a los que se accede v´ıa modelo de programaci´on request-response, un componente Web que se ejecuta dentro de un contenedor web y genera contenido din´amico. JSP es una tecnolog´ıa Java que permite generar contenido din´amico para web, en forma de documentos HTML, XML o de otro tipo, es una manera alternativa, y simplificada, de construir servlets, pero con la posibilidad de a˜nadir c´odigo java en forma de scripts como complemento al c´odigo HTML, de esta manera se puede generar el contenido de la p´agina a partir de objetos en el servidor, un ejemplo ser´ıa dibujar una tabla de la que a priori no se conoce su n´umero de filas, un factor que cambia seg´un el contexto de ejecuci´on, con JSP incrustar´ıamos c´odigo Java en la p´agina que recorriera dicha tabla y generase el c´odigo HTML correspondiente a la tabla actual. A.2. Tecnolog´ıa WebSockets del lado del servidor Tabla A.2: Esta tabla presenta el software del lado del servidor que soporta el protocolo WebSockets, clasificado por lenguaje de implementaci´on. [Extra´ıdo de http://en.wikipedia.org/wiki/WebSocket] 51 A.3. Diferencias entre HTML5 y HTML4/XHTML Tabla A.3: Tabla de diferencias entre HTML5 y HTML4 (parte 1). En amarillo aquellas etiquetas introducidas en esta nueva versi´on, en azul las etiquetas que han sido cambiadas todo o en parte y en gris las etiquetas eliminadas de esta versi´on. Si bien en la pr´actica los navegadores no lo est´an teniendo en cuenta para evitar perder cuota de mercado. [Extra´ıdo de http://es.wikipedia.org/wiki/HTML5] 52 Tabla A.4: Tabla de diferencias entre HTML5 y HTML4 (parte 2). En amarillo aquellas etiquetas introducidas en esta nueva versi´on, en azul las etiquetas que han sido cambiadas todo o en parte y en gris las etiquetas eliminadas de esta versi´on. Si bien en la pr´actica los navegadores no lo est´an teniendo en cuenta para evitar perder cuota de mercado. [Extra´ıdo de http://es.wikipedia.org/wiki/HTML5] 53 del cuestionario. Tras el cuestionario se llega a la p´agina de despedida, en ella se muestra un mensaje de fin de partida y existe un bot´on que nos permite volver a la p´agina de comienzo. Por ´ultimo, en la figura B.2 se observa una captura de la misma. Figura B.2: Captura de adminBarrier.html (arriba-izquierda), de explicacion.html (arribaderecha), de cuestionario.html (abajo-izquierda) y de game over.html (abajo-derecha) B.1.2. Arquitectura cliente-servidor La funci´on principal del sistema, est´a construida sobre una arquitectura de tipo cliente-servidor basada en la tecnolog´ıa WebSockets. En la parte del cliente mediante una combinaci´on de HTML5, CSS y JavaScript se gestiona el aspecto gr´afico, el movimiento del cuadrado receptor sobre la l´ınea al mover el rat´on, la cuenta atr´as antes de una ronda, el cron´ometro, el marcador de colisiones activas, cambios en la informaci´on de ayuda seg´un el estado, aparici´on y desaparici´on de la zona de respuesta o de cambio de ronda, y por su puesto, con JavaScript, la implementaci´on de WebSockets en la parte del cliente, gracias a la cual el cliente puede conectarse y desconectarse del servidor, enviar mensajes (JSON) y recibir y procesar los originados en el servidor. En la parte del servidor, se controla el ciclo de estados de la ronda en el cliente, el reparto de emparejamientos entre participantes, el intercambio de informaci´on de posicionamiento del receptor entre jugadores persona con jugadores persona y/o jugadores m´aquina, la creaci´on de bots, gesti´on de su comportamiento seg´un el modo en que se encuentren, almacenado de informaci´on de ronda y c´alculos para generar el ranking correspondiente. El comportamiento del servidor al conectarse un cliente es el de generar un objeto de la clase GameConnection, que representa al cliente en el servidor, en esta clase es donde se implementa el comportamiento del servidor frente interacciones originadas en el cliente, al conectarse o desconectarse, la recepci´on y env´ıo de mensajes, al igual 60 que se hace con JavaScript en la parte del cliente. Si el cliente que se conecta es el primero, es el encargado de generar todos los bots u objetos BotPlayer indicados por el par´ametro maxBots. Cada objeto BotPlayer crea a su vez un objeto BotThread en el cual se ejecuta el bucle principal del comportamiento del bot, mientras se est´a jugando una ronda, en un hilo de ejecuci´on paralelo para no bloquear la aplicaci´on. En la figura B.3 pueden observarse dos esquemas simplificados a modo de ejemplo de las conexiones y relaciones que se crean en la arquitectura de la aplicaci´on seg´un el tipo de ronda. El primero es una ronda entre dos jugadores persona y el segundo una ronda entre un jugador persona y otro jugador m´aquina: Figura B.3: Diagrama que hace referencia a la arquitectura en una ronda entre dos jugadores persona (izquierda). Diagrama que hace referencia a la arquitectura en una ronda entre un jugador persona y otro jugador m´aquina (derecha): B.1.3. Modos de juego La aplicaci´on soporta tres modos de juego, que permiten reproducir experimentos originales y crear otros nuevos: normal, m´ultiple (tiempo) y m´ultiple (p´ıxel).. El modo normal permite representar el experimento de Iizuka y Di Paolo (2007)[25] y el de Iizuka et al.(2009[24],2012a[22]). Una ronda de este tipo es de uno contra uno, bien entre “persona vs persona”o“persona vs bot”. Durante el tiempo delimitado el jugador mover´a su cuadrado receptor interactuando con el de su adversario. Una vez finalizado ese tiempo el jugador debe responder a la cuesti´on de si ha interactuado con una m´aquina o una persona. Dependiendo del valor del par´ametro botModeLoop, la evoluci´on de los bots cambia. Si es igual a 0, el modo de los bots siempre ser´a el mismo, el que marque la propiedad botFirstMode, no cambiar´a durante el transcurso de la rondas de una vuelta. Si es mayor que cero, los bots ir´an pasando por los diferentes modos disponibles (RANDOMSIMPLE, SHADOW, DELAYEDSHADOW y COMPLEX) seg´un avancen las rondas El modo m´ultiple con retardo por tiempo se corresponde a un combinaci´on del experimento original de Auvray et al.(2009)[5] a˜nadi´endole la dimensi´on temporal del de Iizuka y Di Paolo (2007)[25]. En una ronda de este modo, cada jugador humano se enfrenta a un contrincante persona, la sombra del mismo con un retardo en milisegundos marcado por el par´ametro de configuraci´on waitTime y un valor fijo de posici´on del cuadrado. Durante el transcurso de la ronda el jugador puede mover el cuadrado receptor para interactuar con el resto de jugadores y hacer click para indicar que piensa que la ´ultima interacci´on ha sido con el jugador humano (hit), contra m´as aciertos mejor. Al finalizar la ronda la informaci´on pertinente es almacenada y el jugador puede avanzar a 61 lasiguienterondaoterminarlavuelta. El modo m´ultiple con retardo por longitud se corresponde con el experimento original de Auvray et al.(2009)[5]. En una ronda de este modo, cada jugador humano se enfrenta a un contrincante persona, la sombra del mismo con una distancia en p´ıxeles marcada por el par´ametro de configuraci´on pixelLength y un valor fijo de posici´on del cuadrado. Durante el transcurso de la ronda el jugador puede mover el cuadrado receptor para interactuar con el resto de jugadores y hacer click para indicar que piensa que la ´ultima interacci´on ha sido con el jugador humano (hit), contra m´as aciertos mejor. Al finalizar la ronda la informaci´on pertinente es almacenada y el jugador puede avanzar a la siguiente ronda o terminar la vuelta. B.1.4. Estados de la aplicaci´on cliente La aplicaci´on cliente pasa por una serie de estados en el desarrollo de cada ronda. Son los siguientes: WAITING: Esperando que llegue un jugador contrincante. PLAYING: Jugando contra otro jugador o jugadores. ANSWERING: respondiendo al cuestionario. WRITING: Escribiendo datos de la ronda en el servidor. SAVED: Escritura en el servidor confirmada. ENDING: Final de la ´ultima ronda de una vuelta. En caso de error tambi´en existe un estado: ERROR: Control de error enviado por el servidor. La figura B.4 contiene un esquema gr´afico del ciclo de estados que sigue la aplicaci´on. Para que todo ´este ciclo se vaya produciendo, el cliente y el servidor intercambian una serie de datos como puede observarse en el diagrama de paso de mensajes, para el caso de una ronda en modo normal, de la figura B.5. Figura B.4: Gr´afico de estado por los que pasa el cliente 62 Figura B.5: Diagrama de paso de mensaje entre cliente y servidor durante una ronda en modo normal B.1.5. Modos de un bot Los diferentes tipos de bot implementados para el proyecto son los siguientes: SIMPLE: Solo env´ıa “MotionInfoMessage”1variando las Xs con un incremento constante de 30 p´ıxeles, cada segundo. Se usaba solo en modo normal. RANDOMSIMPLE: Solo env´ıa “MotionInfoMessages”, las Xs se env´ıan cada medio segundo con un valor aleatorio entre 0 y 800. Se usa solo en modo normal. SHADOW: Solo env´ıa“MotionInfoMessages”, el valor de las Xs y su instante de lanzamiento siguen la traza de un jugador persona realizada anteriormente. Se usa solo en modo normal. DELAYEDSHADOW: Recibe y env´ıa “MotionInfoMessages”, repite la traza de Xs de la persona con la que est´a jugando la ronda actual, con un retraso en milisegundos definido por el par´ametro de configuraci´on waitTime. Se usa en modo normal y m´ultiple con retraso por tiempo. 1Nota: “MotionInfoMessage” es un mensaje de posicionamiento de cuadrados que intercambian los jugadores durante una ronda al mover el cuadrado. 63 COMPLEX: Recibe y env´ıa “MotionInfoMessages”, este bot sigue pol´ıticas de comportamiento frente a los mensajes que le lleguen de jugador oponente persona. Hay definidas dos pol´ıticas: acercarse al oponente o alejarse del mismo. La primera posici´on del bot es 0, cuando al bot le llega una Xs modifica el valor de su Xs, sumando si el oponente esta a la derecha o restando si esta a la izquierda un n´umero aleatorio entre 1 y una velocidad m´axima. Durante el tiempo que no recibe mensajes del oponente, el bot no est´a ocioso, si no que incrementa una variable que delimita la velocidad de env´ıo de mensajes, de tal manera que cuando es m´ultiplo de un n´umero grande dado se lanza un mensaje que sigue la pol´ıtica de acercarse, de esta manera no se satura la comunicaci´on con mensajes del bot. Las pol´ıticas de acercamiento o alejamiento puede ser reprogramadas como interese, las actuales son las que pienso ofrecen mayor dificultad al jugador persona. Se usa solo en modo normal. PIXELSHADOW: Recibe y env´ıa “MotionInfoMessages”, retransmite la traza de Xs de la persona con la que est´a jugando la ronda actual, menos una distancia en p´ıxeles marcada por el par´ametro pixelLength. Si el resultado de la diferencia es negativo, se recalcula el valor de X sum´andole 800 de esta manera aparece por el otro extremo. Se usa solo en modo m´ultiple con retraso por distancia en p´ıxeles. B.1.6. Caracter´ısticas y limitaciones A continuaci´on una lista de caracter´ısticas y limitaciones de la aplicaci´on: El servlet WebSocket y conexi´on al servidor durante una vuelta de rondas est´an centrados en una ´unica p´agina, juego.html. La aplicaci´on se ejecuta de forma correcta en el navegador Mozilla Firefox, no se asegura su buen funcionamiento en otros navegadores. El n º de jugadores debe ser un n º par, por implementaci´on. Hasta que no se completa el n º m´aximo de jugadores no empieza la partida, ya que es el ´ultimo jugador persona en entrar el que reparte los mensajes de emparejamiento. Igual pasa al final de una ronda no terminal. Los mensajes transmitidos entre cliente-servidor en ambos sentidos son cadenas de texto JSON (JavaScript Object Notation). Tambi´en se usa esta notaci´on para almacenar la informaci´on de la ronda de un jugador persona en un fichero de texto externo. El reparto de parejas, en modo normal, se hace de la forma siguiente: 1. Se construyen una lista de jugadores personas y otra de jugadores bots, a partir de los “Maps” de la clase principal. 2. Se coge el primer bot persona y usando la funci´on “Math.random()” de java se elige a su pareja que puede ser tanto persona como m´aquina. 3. Se env´ıa a los clientes persona un “PairingInfoMessage”2y se llama a la funci´on que inicia el bucle de los bots. 4. Se borran de sus listas correspondientes los jugadores emparejados. 5. Se repite el bucle hasta que todos los jugadores persona tienen pareja. El reparto de parejas, en modo m´ultiple, se hace de la forma siguiente: 1. Se construyen una lista de jugadores personas y otra de jugadores bots DELAYEDSHADOW o PIXELSHADOW, a partir de los “Maps” de la clase principal. 2“PairingInfoMessage” es el tipo de mensaje que el servidor env´ıa a los jugadores persona para informarles de los emparejamientos formados. 64 2. Se generan dos n´umeros distintos usando la funci´on “Math.random()”, los cuales indican los dos jugadores persona del emparejamiento. 3. Se cogen los dos primeros bots de la lista se asignan individualmente como bots sombra a cada jugador persona del emparejamiento. 4. Si se esta en modo m´ultiple con retraso en milisegundos, se genera un n´umero aleatorio con la funci´on java con un valor comprendido entre 0 y 800, este es el valor fijo que se asocia a ambos jugadores persona. Si por el contrario, se esta en modo m´ultiple con distancia en p´ıxeles, se generan otros dos n´umeros aleatorios en vez de solo uno, uno de 0 a 400 y otro de 401 a 800, que son los valores fijos que se asocian cada uno a un jugador persona distinto. 5. Se env´ıa a los clientes persona un “PairingInfoMessage” y se llama a la funci´on que inicia el bucle de los bots. 6. Se borran de sus listas correspondientes los jugadores emparejados. Se repite el bucle hasta que todos los jugadores persona tienen pareja. La evoluci´on de los modos de un bot en modo normal, durante las sucesivas rondas jugadas por el mismo, siguen un orden secuencial, por implementaci´on:  RANDOMSIMPLE, SHADOW, DELAYEDSHADOW y COMPLEX. Existe un fichero de configuraci´on con notaci´on JSON llamado configuration.json, que el servidor lee nada m´as arrancar para tomar los valores iniciales de variables globales, sus valores por defecto son:  {"numPairs":0,"maxPlayers":2,"maxBots":1,"waitTime":400,"pixelLength":100,"roundMax":4, "maxTime":15,"botFirstMode":0,"winners":0, "multipleMode":0,"multRanking":0,botModeLoop":1, "collTimeout":200} B.1.7. Errores tratados gr´aficamente Hay una serie de errores que se controlan y muestran de forma gr´afica para informar al cliente del problema. En caso de una ca´ıda del servidor mientras se est´a en la pantalla de juego se muestra el error de la figura B.6, reescribiendo el c´odigo HTML de la misma p´agina. Figura B.6: Error producido al desconectarse de forma inesperada el servidor. Si se produce el intento de conexi´on con el servidor de un cliente con el mismo identificador que otro ya conectado, se rechaza, un ejemplo de c´omo puede darse el caso es si en un mismo navegador se abre una nueva pesta˜na y se intenta conectar. En la figura B.7 puede observarse el mensaje que se mostrar´ıa por pantalla. Si mientras dos jugadores humanos enfrentados juegan su ronda, uno de ellos pierde la conexi´on sin haber terminado la cuenta atr´as del cron´ometro, al jugador todav´ıa conectado se le informa del suceso y se le da la oportunidad de repetir la ronda, como se muestra en la figura B.8. 65 Figura B.7: Error producido al intentar conectarse un segundo jugador persona con el mismo identificador de conexi´on. Figura B.8: Error producido al desconectarse el jugador oponente mientras se estaba jugando. B.2. Filtro de par´ametros de configuraci´on Como se ha comentado en la subsecci´on B.1.1 de este cap´ıtulo, en la p´agina de administraci´on hay implementado un filtro, para que en caso de que se incumpla una norma no se modifique dato alguno. Las reglas son: 1. maxPlayers debe ser mayor igual que 2 2. maxPlayers debe ser m´ultiplo de 2 3. maxBots debe ser menor igual que el n º de jugadores humanos 4. numPairs debe ser mayor igual que 0 5. waitTime debe ser mayor que 0 6. pixelLength debe ser mayor que 0 7. roundMax debe ser mayor que 0 8. maxTime debe ser mayor que 0 9. botFirstMode debe ser un valor entre 0 y 3, sin incluir el 1 10. botFirstMode debe ser distinto de 1 ->Modo SHADOW dependiente de un estado anterior 11. winners debe ser mayor igual que 0 12. winners debe ser menor igual que el n º de jugadores humanos 66 13. multipleMode debe ser un valor entre 0 y 2 14. En modo m´ultiple el n´umero de jugadores humanos debe ser m´ultiplo de 2 15. En modo m´ultiple maxBots debe ser igual que el n de jugadores humanos 16. multRanking debe ser un valor entre 0 y 1 17. botModeLoop debe ser mayor igual que 0 18. collTimeout debe ser mayor que 0 B.3. Bocetos iniciales de la p´agina web FiguraB.9:Bocetodelap´agina inicial de la aplicaci´on. Figura B.10: Boceto de la p´agina de explicaci´on de la aplicaci´on. 67 Figura B.11: Boceto de la p´agina de juego durante una ronda. Figura B.12: Boceto de la p´agina de juego al responder el cuestionario. Figura B.13: Boceto de la p´agina final de la aplicaci´on 68 B.4. Capturas de las p´aginas de la aplicaci´on Figura B.14: Captura de la p´agina inicial de la aplicaci´on. Figura B.15: Captura de la p´agina de explicaci´on de la aplicaci´on. 69 Figura C.1: Captura del visor para trazas generadas en modo normal. La ventana del gr´afico de fase, mencionada antes, es compartida por todos los visores. Como se puede observar en la figura C.2 la ventana del gr´afico de fase tiene dos zonas bien diferenciadas. La zona superior contiene la gr´afica, en el eje de abscisas se representa la posici´on del receptor en p´ıxeles y en el de ordenadas el diferencial de la posici´on del cuadrado respecto del diferencial del tiempo. La zona inferior contiene a su vez dos zonas. La de la izquierda muestra el nombre del jugador del que se guardo la traza actual y el del su contrincante, tambi´en tienen un “checkbox” para hacer invisible o visible la traza de cada uno en la gr´afica; en la de la derecha se muestra informaci´on editable sobre los l´ımites de la gr´afica, al cambiar dichos valores se podr´a centrar la atenci´on en la parte de la gr´afica que m´as interese, tambi´en contiene un bot´on de “Reset” que reinicializa estos valores a los de por defecto. Figura C.2: Captura de la ventana de gr´afico de fase. 76 En la figura C.3 se muestra una captura del interfaz para modo m´ultiple con retraso de tiempo en milisegundos. Como puede observarse este modo tambi´en tiene tres zonas bien diferenciadas. La zona superior es igual a la del otro visor, permite cargar el fichero deseado de datos a estudiar. En la zona intermedia se muestra la gr´afica estudiada, al igual que el visor anterior, en el eje de ordenadas se representa la posici´on del receptor en p´ıxeles y en el de abscisas el instante temporal en milisegundos, pero en este visor pueden aparecer muchas m´as trazas, ya que existen m´as interlocutores en este experimento y m´as par´ametros a manejar. La zona inferior se divide en tres zonas: la m´as a la izquierda se divide en dos, la superior contiene un bot´on para cargar la gr´afica de la siguiente ronda del experimento y otro para cargar la anterior, en la inferior se muestra informaci´on editable sobre los l´ımites de la gr´afica, al cambiar dichos valores se podr´a hacer un zoom en la parte del gr´afica que m´as interese, tambi´en contiene un bot´on de“Reset”que reinicializa los limites de las dimensiones al caso inicial por defecto; la zona contigua muestra informaci´on de la partida, el n´umero de experimento, nombre del jugador del que se almaceno la informaci´on, el de su contrincante, el n´umero de clicks total¸ los acertados y los fallidos, el n´umero de colisiones activas total, las ocurridas con humanos y las acaecidas con bots, salvo el identificador de partida, el resto de campos tiene adem´as un “checkbox” para hacer visible o no la traza correspondiente y los mismo para las trazas de la sombra del jugador que guardo la informaci´on actual, la de su contrincante y el valor fijo; la ´ultima contiene un “checkbox” para hacer visible una nueva ventana donde se muestra un gr´afico de fase, la cual ya he descrito en un p´arrafo previo. Figura C.3: Captura del visor para trazas generadas en modo m´ultiple con retraso de tiempo en milisegundos. La figura C.4 contiene el ´ultimo visor a estudiar, ´el de modo m´ultiple con distancia en p´ıxeles. Como puede observarse en la imagen el interfaz de este modo es pr´acticamente el mismo que el del visor m´ultiple con retraso en milisegundos, salvo por la parte central y derecha de la zona inferior del mismo. Aparecen nuevos campos como son el del n´umero de clicks y colisiones con la sombra del contrincante y con el valor fijo asignado al jugador que guardo la informaci´on y aparece una nueva traza de valor fijo, ya que en este modo los dos jugadores tienes diferente valor fijo asignado. Como se observa han desaparecido el n´umero de clicks fallo y de colisiones con bots en total, ya que son par´ametros que se pueden calcular a partir del valor de los incluidos. La zona m´as a la derecha queda dividida en dos zonas, la superior con el “checkbox” para mostrar la ventana del gr´afico de fase y el bot´on de carga del gr´afico en s´ı mismo; en la zona inferior un “checkbox” para mostrar 77 otra ventana con una tabla de ratios, como ejemplo la ventana de la figura C.5, contiene una tabla con tres filas y tres columnas. La columnas representan a cada uno de los jugadores adversario, el jugador persona (PAIR), la sombra del mismo (SHADOW2) y el valor fijo (FIXED). Las filas representan las ratios a calcular, la primera el porcentaje de colisiones activas con el jugadorcolumna respecto del total, la segunda el porcentaje de clicks acertados con el jugador-columna respecto del total y la tercera el cociente del n´umero de clicks acertados con el jugador-columna entre en n´umero de colisiones activas con el mismo. Figura C.4: Captura del visor para trazas generadas en modo m´ultiple con distancia en p´ıxeles. Figura C.5: Captura de la ventana de tabla de ratios en modo m´ultiple con distancia en p´ıxeles. 78 C.2. Gr´aficas EJS C.2.1. Gr´aficas posici´on receptor - tiempo Figura C.6: Modo normal: Persona vs Bot RANDOMSIMPLE Figura C.7: Modo normal: Persona vs Bot SHADOW 79 Figura C.8: Modo normal: Persona vs Bot DELAYEDSHADOW Figura C.9: Modo normal: Persona vs Bot COMPLEX Figura C.10: Modo normal: Persona vs Persona 80 Figura C.11: Modo M´ultiple: Retardo de sombra en milisegundos Figura C.12: Modo M´ultiple: Retardo de sombra en p´ıxeles 81 C.2.2. Gr´aficas de fase Figura C.13: Modo normal: Persona vs Bot RANDOMSIMPLE (izquierda) y Persona vs Bot SHADOW (derecha) Figura C.14: Modo normal: Persona vs Bot DELAYEDSHADOW (izquierda) y Persona vs Bot COMPLEX (derecha) 82 Figura C.15: Modo normal: Persona vs Persona Figura C.16: M´ultiple: Retardo de sombra en milisegundos (izquierda) y Retardo de sombra en p´ıxeles (derecha) 83 84 Anexo D Datos en formato JSON Los datos intercambiados entre cliente y servidor WebSocket, seg´un el trabajo que desempe˜nan, se pueden dividir en datos de configuraci´on de la aplicaci´on, de emparejamiento de jugadores durante las rondas, del estado del cliente, de errores producidos, de informaci´on ´util de la ronda que se almacena, del cuestionario del modo normal y de movimiento del cuadrado receptor. D.1. Configuraci´on En la parte de configuraci´on he utilizado dos estructuras JSON distintas. Una de ellas es la de los mensajes que se env´ıan al principio de cada vuelta de rondas a los clientes para que puedan configurar sus variables clave, como son el n´umero de rondas de la vuelta, la duraci´on de cada ronda, el modo de juego, el tipo de ranking y la sensibilidad ante clicks tras una colisi´on. La tabla D.1 contiene la estructura de un mensaje de tipo configurationInfo. La otra estructura de configuraci´on es el contenido del fichero de configuraci´on“configuration.json”, un fichero de texto que determina los par´ametros clave para que la aplicaci´on funcione de una manera u otra. Este fichero puede ser modificado bien de forma manual o a trav´es de la pagina de administraci´on “adminBarrier.html”. De forma autom´atica tambi´en es modificado al terminar una vuelta de rondas completa, ya que se actualiza el valor del par´ametro numPairs, almacenando la id del pr´oximo emparejamiento a repartir. Si se produce una segunda vuelta de rondas debido a que el valor del par´ametro winners es mayor que cero, la propia p´agina de ranking debe modificar en n´umero de jugadores necesarios, actualizando el valor de maxPlayers y de maxBots en el fichero de configuraci´on. En la tabla D.2 puede observarse la estructura del fichero. {"configurationInfo":{ //Nombre identificativo del tipo de mensaje. "roundMax":valorRoundMax, //N´umero de rondas del experimento. "maxTime":valorMaxTime, //Tiempo en segundos de cada ronda. "multipleMode":valorMultipleMode, //Indica el modo en que se juega la vuelta. Si es igual a 0 modo //normal, si es 1 modo m´ultiple(tiempo) y si es 2 modo //m´ultiple(p´ıxel). "multRanking":valorMultRanking, //En modo m´ultiple indica el tipo de ranking a generar tras una //vuelta completa de rondas. "collTimeout":valorCollTimeout}} //Indica el tiempo m´aximo en milisegundos en el cual, tras //producirse una colisi´on, si se hace click se considera colisi´on. Tabla D.1: Estructura del tipo de mensaje configurationInfo, con comentarios de sus componentes. 85 MODO M ´ ULTIPLE (P´ IXEL) Exp7: [M´aq remota(persona) + Bot PixelShadow + Fixed1] vs [M´aq remota(persona) + Bot PixelShadow + Fixed2] (10) Total de rondas a jugar = 160 E.2. Datos a medir y metodolog´ıa a seguir Los datos a medir siempre van a hacer referencia a la partida y trazas de los jugadores persona. Habr´a que a˜nadir instrumentaci´on para que de forma gr´afica se puede obtener tras una ronda el n´umero de mensajes recibidos y enviados y un tiempo de juego que se puede tomar del m´aximo del crono o con la diferencia de un par de estampillas temporales al inicio y fin de la ronda por ser m´as meticulosos. Estos datos ir´an a una hoja de c´alculo donde se sacar´an mensajes enviados/recibidos por unidad de tiempo. Luego en modo off-line con un programa habilitado al caso se har´a un an´alisis de las trazas de las partidas, all´ı se medir´an las diferencias de tiempo entre un mensaje enviado y el siguiente, para calcular la velocidad m´axima media de env´ıo, comprobando la sensibilidad del escuchador de captura del evento de movimiento de rat´on, ya que, por cada captura se env´ıa un mensaje. Estos datos tambi´en se almacenar´an en una hoja de calculo para su posterior estudio. E.3. Metodolog´ıa de juego durante una ronda Se modificar´a la evoluci´on normal en los modos de los bots (0,1,2,3) en el modo normal, para que se puedan hacer todas las mediciones del modo a estudiar de forma seguida, lo que resulta m´as pr´actico y simple. En el caso especial del modo SHADOW (1) que es dependiente de una partida anterior para poder jugarla se le pondr´a siempre la misma partida. Durante una partida se seguir´a una estrategia por la cual se mover´a el rat´on de un lado a otro los m´as r´apido posible, para que los datos recogidos sean lo m´as fidedignos posible a la idea de medir los l´ımites de la tecnolog´ıa utilizada para implementar la aplicaci´on. Los nombres de los ficheros a almacenar empezaran por“e”seguido del n´umero de experimento, en el caso del 3 y el 6 de dos n´umeros, adem´as si hay m´as de un jugador persona, en el caso del 5, el 6 y el 7, se a˜nade p1 para el primer jugador y p2 para el segundo. Ejemplos de nombre: e1 18-3-2013 5h58m11s.txt, e2 18-3-2013 6h02m19s.txt, e33 18-3-2013 6h30m08s.txt, e65p2 18-3- 2013 8h02m39s.txt ... E.4. Equipos de prueba PC1 S.O Windows 7 Professional, Service Pack 1 Procesador Intel(R) Core(TM) i7-2600 CPU @3.40GH RAM 6.00 GB Arquitectura 64 bits Tabla E.1: Tabla de caracter´ısticas del PC1. 92 PC2 S.O Windows 7 Professional, Service Pack 1 Procesador Dual Core AMD Opteron(tm) Processor 275 2.20GHz (2 procesadores) RAM 3.70 GB Arquitectura 64 bits Tabla E.2: Tabla de caracter´ısticas del PC2. En el PC1 se han hecho las pruebas en modo normal contra bots y representa al jugador 1 en las partidas con m´as de una persona. El PC2 representa al segundo jugador persona. E.5. Medidas Estas son las medidas obtenidas de cada experimento, como puede observarse cada tabla tiene tres datos de inter´es como son, en orden descendente, la media de mensajes enviados por segundo, la media de mensajes recibidos por segundo y la diferencia media total entre mensajes enviados. Algo que observ´e, durante la toma de medidas, es que la primera ronda de todos los experimentos tiene una tasa de mensajes enviados mucho mayor que el resto de rondas, lo achaco a que en el cliente en primera instancia no hay memoria reservada todav´ıa para las estructuras de datos que sirven para almacenar la informaci´on de una ronda y dem´as datos auxiliares, que se van creando precisamente en esta primera partida. Por ello, considero el primer dato de cada experimento como un dato at´ıpico que podr´ıa mejorar las prestaciones temporales de la aplicaci´on notablemente, no lo he incluido en la medias calculadas para que mis datos sean m´as fidedignos y se centren en el grueso de informaci´on m´as representativa, ya que en las siguientes rondas de los experimentos los tiempos calculados no difieren tanto unos de otros. E.5.1. Modo normal En modo normal la media de mensajes enviados por segundo m´ınima es de 53,0603 y la m´axima 60,7565, lo que nos hace movernos entre 17,84 y 16,46 milisegundos por mensaje enviado. En el caso de la media de mensajes recibidos por segundo hay una m´axima de 88,7562 en el caso del bot SHADOW y una m´ınima de 1,9983 en el bot RANDOMSIMPLE, estos datos no son realmente significativos, ambos modos tienen una traza constante, solo env´ıan mensajes, no los reciben, siempre van a darse en las mismas cantidades salvo latencia a˜nadida por el medio de comunicaci´on, adem´as el bot SHADOW tiene la traza de una primera ronda por eso ese valor tan alto. Si observamos el resto de experimentos, no constantes, se tiene una m´axima de 60,4881 y una m´ınima de 45,1400. Para el tercer par´ametro en estudio, la diferencia media entre mensajes enviados, tiene un m´aximo de 19,0702 milisegundos entre mensaje y mensaje enviado y un m´ınimo de 16,5686 milisegundos entre mensajes enviados, como se observa, son valores similares a los obtenidos a trav´es de la media de mensajes enviados por segundo, dos formas de calcular la velocidad de envi´o de la aplicaci´on. En el experimento 4 y 4b, quer´ıa comprobar si a˜nadir el guardado de la traza del bot COMPLEX, durante una ronda, para luego poder representar esta traza en el visor de gr´aficas correspondiente, merec´ıa la pena y no a˜nad´ıa una latencia significativa. Como se puede comprobar en los datos de la figura E.3 los valores obtenidos son semejantes, incluso algo mejores en el caso 4b, lo que justifico con un mejor comportamiento del servidor y/o del jugador persona. 93 Figura E.1: Medidas obtenidas en experimento 1 y experimento 2. Figura E.2: Medidas obtenidas en experimento 3. Figura E.3: Medidas obtenidas en experimento 4 y experimento 4b. Figura E.4: Medidas obtenidas en experimento 5. Uno de los casos m´as interesantes dentro de este modo es el tercer experimento, en el bot DELAYEDSHADOW, aparecen las mayores latencias, tanto por el hecho de que el servidor espera la traza del jugador persona, para reenviarla con un retraso marcado, como por el propio retraso generado en el servidor a trav´es de sleeps. Como se ha observado antes la m´axima diferencia entre mensajes enviados es, redondeando, de unos 20 milisegundos, lo que necesitamos para completar el ciclo de ida, de cliente al servidor, y vuelta, del servidor al cliente, es este segundo camino. Como se observa en la figura E.5 se muestra una tabla con la media de mensajes recibidos entre el tiempo real. Llamo tiempo real al tiempo total de la ronda menos el retraso correspondiente del experimento. Se obtiene una media de 48,6905 mensajes recibidos por segundo, por lo que se est´an recibiendo mensajes del servidor cada 20,5379 milisegundos. Sumando este tiempo con el anterior obtenemos un par´ametro clave de la aplicaci´on, lo que le cuesta a un mensaje enviado desde un cliente fuente llegar a un cliente destino, es decir, cuando dos usuarios est´en jugando una ronda, los mensajes que le llegan a uno desde el otro llevar´an como m´aximo una desincronizaci´on de 40-50 milisegundos. 94 Figura E.5: Tabla de mensajes recibidos en tiempo real del experimento 3. E.5.2. Modo m´ultiple Como puede observarse en las tablas una de las diferencias entre el modo normal y el m´ultiple, es que el volumen de mensajes recibidos por segundo es pr´acticamente el doble, debido al hecho de que cada jugador humano esta recibiendo dos flujos de datos pertenecientes a un jugador persona y un bot sombra. Se tiene un m´aximo de 62,9977 mensajes enviados por segundo y un m´ınimo de 32,7985, por lo que nos movemos entre los 15,87 y los 30,49 milisegundos por mensaje enviado. El m´ınimo anterior lo achaco a un problema con la superficie por la que se mov´ıa el rat´on, que ofrec´ıa m´as resistencia que en anteriores pruebas. En cuanto al n´umero medio de mensajes recibidos por segundo, hay un m´aximo de 119,8763 y un m´ınimo de 92,5227, como he indicado antes casi se duplican los datos del modo normal. El tiempo entre mensajes enviados se mueve entre 16,0804 y 31,1188 milisegundos, este segundo dato coincide con el peor caso de mensajes enviados por segundo, motivado por la misma causa. Figura E.6: Medidas obtenidas en experimento 6. 95 Figura E.7: Medidas obtenidas en experimento 7. Al igual que en el modo normal el caso m´as interesante dentro del modo m´ultiple es el sexto experimento, ya que dentro de los componentes del experimento hay dos bots sombra de tipo DELAYEDSHADOW, por lo que aparecen las mayores latencias. La m´axima diferencia entre mensajes enviados es de unos 30 milisegundos, para obtener el tiempo de la vuelta he realizado una serie c´alculos cuyo resultado puede verse en la figura E.8, en ella se muestra una tabla con la media de mensajes recibidos entre el tiempo real por experimento. Se obtiene una media de 105,4876 mensajes recibidos por segundo, por lo que se est´an recibiendo mensajes del servidor cada 9,4798 milisegundos, hay que tener en cuenta que se incluyen los mensajes del oponente persona y del bot sombra. Como la cantidad de mensajes enviados por el bot sombra siempre va a ser inferior al del jugador persona, del flujo de mensajes que llegan al jugador destino representar´an algo menos de la mitad, cogiendo la mitad de la media anterior obtendr´ıamos un tiempo entre mensajes recibidos provenientes del bot sombra de 18,96 milisegundos, redondeando unos 20 milisegundos. Sumando tiempos, los mensajes que le llegan a un jugador desde otro llevar´an como m´aximo una desincronizaci´on de 50 milisegundos. Figura E.8: Tabla de mensajes recibidos en tiempo real del experimento 6. 96 E.5.3. Tiempos aplicaci´on vs Experimento Iizuka y Di Paolo (2007) Como se ha descrito en las secciones anteriores el tiempo m´aximo que tarda en llegar un mensaje de un cliente a otro es de 50 milisegundos, es decir, un jugador detecta el movimiento del receptor de otro jugador con una desicronizaci´on m´axima de 50 milisegundos. Si observamos la gr´afica de la figura E.9, que hace referencia al experimento realizado por Iizuka y Di Paolo (2007)[25], vemos la diferencia entre las dos trayectorias de los agentes para el caso de interacciones en vivo (l´ınea continua) y para el caso de interacciones con una grabaci´on (l´ınea discontinua). En principio ambas trazas no difieren mucho, la diferencia entre trayectorias no supera las 100 unidades de longitud, pero a partir de 400 milisegundos de desfase la diferencia para el caso unilateral aumenta considerablemente perdiendo la coordinaci´on. En el caso de la aplicaci´on no a˜nade un desfase superior a 50 milisegundos por lo que se podr´a llegar a la coordinaci´on de interacciones sin problema. Figura E.9: Diferencia entre las dos trayectorias en cada condici´on. Cuando la l´ınea cruza 0 significa que dos agentes se cruzan entre s´ı. 97 98 Anexo F Par´ametros comparables En este ap´endice quer´ıa a˜nadir informaci´on que permitiera comparar par´ametros del experimento de Auvray et al. (2009)[5]1y par´ametros de la aplicaci´on desarrollada en este proyecto, a la vez que resumiera datos, que pueden resultar de inter´es, para el estudio de ambos casos . En las tablas F.12y F.2 se muestra la informaci´on comparable de cada parte: Par´ametros Longitud espacio unidimensional 800 p´ıxeles. Tama~no informaci´on compartida 50 bytes(fuente, posici´on, n´umero de mensaje) de forma as´ıncrona. Longitud campo receptor 50 p´ıxeles. Entrada sensorial Visual (color cuadrado, marcador colisiones) y auditiva (efecto Doppler), una mano mueve el rat´on. Oponentes por experimento Modo Normal: 1 vs 1 (entre personas o persona y bot). Modo M´ultiple: oponente persona, su sombra y valor fijo. Distancia entre el se~nuelo m´ovil La que se desee (configurable, por defecto 100 p´ıxeles), tambi´en posible sombra con retardo en milisegundos(tambi´en configurable, por defecto 400 milisegundos). tasa testeo estimulos-click Sistema as´ıncrono, en el momento de hacer el click registra est´ımulos (colisiones). Una colisi´on tiene una vida m´axima entre clicks de 200 milisegundos, por defecto, valor ajustable. Personas por prueba Modo Normal: 1 o 2 personas. Modo M´ultiple: 2 personas. Tipos de objeto no persona Modo Normal: RANDOMSIMPLE, SHADOW, DELAYEDSHADOW y COMPLEX. Modo M´ultiple: DELAYEDSAHDOW, PIXELSHADOW y valor fijo. Formato de datos almacenados JSON Tabla F.1: Informaci´on de la aplicaci´on desarrollada en el proyecto. 1Para tener una descripci´on m´as detallada del experimento ir a la secci´on 2.2 del cap´ıtulo 2 de la memoria 2Descripci´on de los tipos de bot en la subsecci´on B.1.5 del ap´endice B. Descripci´on de datos almacenados en la secci´on D.5 del ap´endice D. 99 Par´ametros Longitud espacio unidimensional 600 p´ıxeles. Tama~no informaci´on compartida 1 bit (todo o nada) de forma s´ıncrona. Longitud campo receptor 4 p´ıxeles. Entrada sensorial T´actil (estimulador t´actil), con una mano se manipula el rat´on y con la otra se percibe los est´ımulos, ojos vendados. Oponentes por prueba cuerpo-objeto persona, se~nuelo m´ovil y se~nuelo fijo. Distancia entre el se~nuelo m´ovil 50 p´ıxeles. tasa testeo estimulos-click cada 2 segundos. Personas por prueba 2 personas. Tipos de objeto no persona Sombra con distancia del oponente persona y fijo (distinto para cada persona). Tabla F.2: Informaci´on del experimento Auvray et al. (2009)[5]. 100 Bibliograf´ıa [1] Abu-akel A. Impaired theory of mind in schizophrenia. Pragmatics and cognition. 1999;7:247—82. 2.1.1 [2] Astington, J. W. (1993). The Child ´ s Discovery of the Mind. Cambridge, MA: Harvard University Press. 1.2, 2.1 [3] Astington, J. W., Harris, P. L. & Olson, D. (Eds.) (1988).Developing theories of mind. Cambridge, UK: Cambridge University Press 1.2, 2.1 [4] Auvray M., Rhode M. (2012). Perceptual crossing: the simplest online paradigm. Front. Hum. Neurosci. 6:181. doi: 10.3389/fnhum.2012.00181. (document), 1.1, 2.2 [5] Auvray M., Lenay C., Stewart J. (2009). Perceptual interactions in a minimalist virtual environment. New Ideas Psychol. 27, 32–47. doi: 10.1016/j.newideapsych.2007.12.002. (document), 1.1, 1.2, 2, 2.2, 2.3, 2.3, 2.4, 2.4, 2, 3, 6.2, B.1.3, F, F.2 [6] Bartsch, K. y Wellman, H. M. (1995). Children Talk About the Mind. New York: Oxford University Press. 2.1 [7] Bishop, D. (1997). Uncommon understanding. Development and disorders of language comprehension in children. Hove: Psychology Press. 1.2, 2.1 [8] Brothers L. The social brain: A Project for integrating primate behavior and neurophysiology in new domain. Concepts in Neuroscience. 1990;1:27—61. 2.1.1 [9] Brown, J., Acz´el, B., Jim´enez, L., Kaufman, S. B., and Plaisted-Grant, K. (2010). Intact implicit learning in autism spectrum conditions. Q. J. Exp. Psychol. 63, 1789–1812. 2.4 [10] De Jaegher, H. (2009). Social understanding through direct perception? Yes, by interacting. Conscious. Cogn. 18, 535–542. 2.4 [11] Di Paolo, E., Rohde, M., and Iizuka, H. (2008). Sensitivity to social contingency or stability of interaction? Modelling the dynamics of perceptual crossing. New Ideas Psychol. 26, 278–294. 1.1, 2.4 [12] Flavell, J.H. (2004). Development of knowledge about vision. In D.T. Levin (Ed.), Thinking and seeing: Visual metacognition in adults and children. Cambridge, MA: M.I.T. Press. 2.1 [13] Flavell, J. H. (2000). Development of children’s knowledge about the mental world.International Journal of Behavioral Development, 24, 15–23. 2.1 [14] Flavell, J. H., & Miller, P. H. (1998). Social cognition. In W. Damon (Series Ed.), D. Kuhn & R. S. Siegler (Eds.), Handbook of child psychology: Vol. 2. Cognition, perception, and language (5th ed., pp. 851–898). New York: Wiley 1.2, 2.1 101