Repositorio Institucional de Documentos

Informática e Ingeniería de Sistemas Departamento de Proyecto Fin de Carrera Ingeniería en Informática Videojuego de coches en red para la evaluación de un sistema P2P de compartición de información Víctor J. Rújula Nasarre de Letosa Directores: Sergio Ilarri Artigas Eduardo Mena Nieto Área de Lenguajes y Sistemas Informáticos Departamento de Informática e Ingeniería de Sistemas Escuela de Ingeniería y Arquitectura Universidad de Zaragoza Agosto 2013 Videojuego de coches en red para la evaluación de un sistema P2P de compartición de información RESUMEN El objetivo de este proyecto es desarrollar un videojuego cuya utilización permita evaluar estrategias de gestión de información en redes vehiculares, una tarea actualmente realizada mediante simuladores, pero que resulta muy costosa debido a la dicultad de ajustar correctamente los parámetros usados por las diferentes estrategias. Con este n, se ha desarrollado un videojuego de coches para múltiples jugadores en red, en el que los jugadores tienen que completar diferentes objetivos en misiones de carácter competitivo mientras circulan por escenarios creados con datos reales obtenidos mediante el sistema de mapas de carretera OpenStreetMap. Para facilitar la explotación del juego como método de evaluación, se han añadido diversos elementos como vehículos no humanos del tráco, vehículos de servicios de emergencia y plazas de aparcamiento que son ocupadas dinámicamente por el tráco y los jugadores. Ha sido necesario el estudio del sistema de gestión de información VESPA para su posterior implementación en el juego, así como también el estudio y la aplicación de diferentes arquitecturas y técnicas de optimización de red y de técnicas de control de los vehículos no humanos. El juego ha sido implementado siguiendo una arquitectura de red de tipo clienteservidor con predicción en el cliente, usando técnicas como la interpolación, la extrapolación y la compresión delta, haciendo uso de los protocolos TCP y UDP. También se han denido los interfaces necesarios para poder integrar en el juego cualquier estrategia de gestión de información, a partir de las cuales se ha desarrollado una implementación del sistema VESPA. Para facilitar la recogida de datos también se ha desarrollado un servidor dedicado, para tener un lugar centralizado desde el cual recopilar dichos datos, y otro proceso con la función de servidor de recogida de estadísticas, el cual recibe la información recopilada por los diferentes servidores durante las partidas. Los resultados obtenidos han demostrado que a pesar de que el videojuego puede suponer una buena herramienta para recopilar mucha información para una gran variedad de escenarios, los resultados obtenidos deben ser tomados con precaución, ya que la pericia del jugador o los elementos introducidos para aumentar la diversión del juego pueden alterar los resultados obtenidos. Por este motivo el videojuego no debe verse como un sustitutivo de los métodos tradicionales de evaluación, como los simuladores, sino como un complemento, ya que puede ayudar a recopilar con menos esfuerzo los datos que serán utilizados para anar el protocolo y también puede servir para obtener conclusiones iniciales previas a la evaluación en el simulador. i Agradecimientos Me gustaría agradecer este Proyecto Fin de Carrera a todas las personas que lo han hecho posible con su apoyo y dedicación. En primer lugar a mis directores de proyecto Sergio Ilarri y Eduardo Mena, por su paciencia y su inestimable ayuda, sin la cual este proyecto no hubiera sido posible. A mis compañeros y amigos de clase, con los que he compartido estos años de carrera, por hacer que esos momentos de estudio y de prácticas fuesen agradables y amenos. A mi familia y amigos más cercanos, por su paciencia y por motivarme para seguir adelante en los momentos más complicados. A mis amigos Dani y Jorge por su inestimable colaboración cuando fue necesario probar el funcionamiento del juego con varios jugadores. A mi ex-compañera de piso Megan, por ayudarme en todas las dudas que me surgieron al traducir los textos y el manual de uso al inglés, así como al resto de compañeros de piso, por haber sido como una segunda familia para mí. Y por supuesto, a la Universidad de Zaragoza y a todos aquellos profesores de los que he aprendido tanto a lo largo de estos años. También debo agradecer el uso que realizo en este proyecto de las librerías JLayer , Xerces , Guava y OpenSteer , y los algoritmos obtenidos del libro Developing Games In Java , así como también a Josh Woodward y Howarang Van K. por el uso de su música. iii Índice general 1. Introducción 1 1.1. Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Objetivos ................................ 1 1.3. Trabajo previo y herramientas . . . . . . . . . . . . . . . . . . . . . 2 1.4. Trabajo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . 5 2. Videojuego desarrollado 7 2.1. Resumendeljuego ........................... 7 2.2. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Menúsdeljuego............................. 10 2.4. Obtención de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Elementos del terreno . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Física .................................. 14 2.7. Inteligencia articial . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7.1. Comportamiento de los vehículos . . . . . . . . . . . . . . . 17 2.7.2. Aplicando Steering behaviors . . . . . . . . . . . . . . . . . 18 2.7.3. Búsqueda de caminos . . . . . . . . . . . . . . . . . . . . . . 19 2.8. Funcionamiento en red . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.8.1. Modelodered.......................... 21 2.8.2. Predicción del lado cliente . . . . . . . . . . . . . . . . . . . 23 2.8.3. Interpolación de entidades . . . . . . . . . . . . . . . . . . . 24 2.9. SistemaVESPA............................. 25 2.10.Menúdepausa ............................. 25 2.11.Sonido.................................. 25 2.12. Modos de juego y gestión de rondas y objetivos . . . . . . . . . . . 26 2.13. Mensajes durante el juego . . . . . . . . . . . . . . . . . . . . . . . 28 3. Explotación 31 3.1. Motivación................................ 31 3.2. Aplicación................................ 32 v 3.3. Limitaciones............................... 34 3.4. Ventajas................................. 36 3.5. Elementos añadidos al juego . . . . . . . . . . . . . . . . . . . . . . 36 3.6. Posibles mejoras de VESPA y problemas encontrados . . . . . . . . 38 3.7. Resultados experimentales . . . . . . . . . . . . . . . . . . . . . . . 38 3.8. Rendimiento del juego . . . . . . . . . . . . . . . . . . . . . . . . . 42 4. Conclusiones 43 4.1. Conclusiones............................... 43 4.2. Línea temporal de la realización del proyecto . . . . . . . . . . . . . 47 4.3. Trabajofuturo ............................. 50 4.4. Valoración personal . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Bibliografía 55 Anexos 59 A. Análisis 61 A.1.Requisitos................................ 61 A.2.Casosdeuso............................... 64 A.3. Diagrama de navegación . . . . . . . . . . . . . . . . . . . . . . . . 84 A.4. Prototipado de ventanas . . . . . . . . . . . . . . . . . . . . . . . . 88 A.5.Modosdejuego............................. 95 B. Diseño 97 B.1. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . . 97 B.2. Capas de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 99 B.3.Despliegue................................100 B.4. Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 B.4.1. Módulo de salida . . . . . . . . . . . . . . . . . . . . . . . . 103 B.4.2. Módulo de menús . . . . . . . . . . . . . . . . . . . . . . . . 106 B.4.3. Módulo gestor de escenarios . . . . . . . . . . . . . . . . . . 110 B.4.4. Módulo de servidor maestro . . . . . . . . . . . . . . . . . . 112 B.4.5. Módulo de servidor estadístico . . . . . . . . . . . . . . . . . 115 B.4.6. Módulo de estadísticas . . . . . . . . . . . . . . . . . . . . . 115 B.4.7.Módulologger..........................119 B.4.8. Módulo de menú in-game . . . . . . . . . . . . . . . . . . . 119 B.4.9. Módulo de terreno . . . . . . . . . . . . . . . . . . . . . . . 122 B.4.10.Módulo gestor de conexiones . . . . . . . . . . . . . . . . . . 123 B.4.11.Módulo de física . . . . . . . . . . . . . . . . . . . . . . . . 127 B.4.12.Módulo de inteligencia articial . . . . . . . . . . . . . . . . 128 vi B.4.13.Módulo cliente . . . . . . . . . . . . . . . . . . . . . . . . . 129 B.4.14.Módulo servidor . . . . . . . . . . . . . . . . . . . . . . . . . 132 B.5. Game Loop (bucle de juego) . . . . . . . . . . . . . . . . . . . . . . 132 B.5.1.Servidor.............................134 B.5.2.Cliente..............................136 B.5.3.Actor...............................138 B.6.Hilosdeejecución............................139 C. Sobre el videojuego 143 C.1.Menúsdeljuego.............................143 C.1.1.Tipografía............................143 C.1.2. Directorio del juego . . . . . . . . . . . . . . . . . . . . . . . 144 C.1.3. Prevención de errores . . . . . . . . . . . . . . . . . . . . . . 146 C.1.4. Pantallas de error . . . . . . . . . . . . . . . . . . . . . . . . 147 C.1.5. Pantallas de mapas . . . . . . . . . . . . . . . . . . . . . . . 147 C.1.6. Otros aspectos importantes . . . . . . . . . . . . . . . . . . 148 C.2. Obtención de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . 149 C.2.1. OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . 149 C.2.2. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . 151 C.2.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . 153 C.3. Elementos del terreno . . . . . . . . . . . . . . . . . . . . . . . . . . 154 C.3.1.Nodos ..............................155 C.3.2.Caminos.............................156 C.3.3. Multipolígonos . . . . . . . . . . . . . . . . . . . . . . . . . 157 C.4. Física y colisiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 C.4.1. Detección de colisión con elementos del terreno . . . . . . . 158 C.4.2. Detección de colisión con otros actores . . . . . . . . . . . . 160 C.4.3. Cálculo de la fuerza resultado de una colisión con otros actores162 C.4.4. Aplicación del resultado de la colisión con el terreno . . . . . 162 C.5. Inteligencia Articial . . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.5.1. Steering behaviors . . . . . . . . . . . . . . . . . . . . . . . 164 C.5.2. Comportamientos complejos . . . . . . . . . . . . . . . . . . 172 C.5.3. Soluciones a las carencias de la IA . . . . . . . . . . . . . . . 177 C.5.4.Path-nding...........................179 C.5.5. Normas de circulación . . . . . . . . . . . . . . . . . . . . . 180 C.6. Funcionamiento en red . . . . . . . . . . . . . . . . . . . . . . . . . 180 C.6.1. Funcionamiento básico . . . . . . . . . . . . . . . . . . . . . 181 C.6.2. Interpolación-extrapolación . . . . . . . . . . . . . . . . . . 184 C.6.3.Predicción............................186 C.6.4. Compresión delta . . . . . . . . . . . . . . . . . . . . . . . . 188 C.6.5. Envío de solo actores cercanos . . . . . . . . . . . . . . . . . 188 vii xiv Índice de tablas 3.1. Conguración de VESPA . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2. Porcentaje de mejora del tiempo de aparcamiento . . . . . . . . . . 40 3.3. Rendimiento obtenido con varias conguraciones . . . . . . . . . . . 42 4.1. Separación de horas por tipo de trabajo . . . . . . . . . . . . . . . . 47 4.2. Separación de horas por iteración . . . . . . . . . . . . . . . . . . . 48 C.1. Estructura de archivo de mapas .dat . . . . . . . . . . . . . . . . . 153 C.2. Posibles valores del terreno . . . . . . . . . . . . . . . . . . . . . . . 164 C.3. Número de usos del cálculo de la distancia entre dos nodos . . . . . 180 C.4. Problema de no enviar actores lejanos . . . . . . . . . . . . . . . . . 189 C.5. Solución al envío de actores no lejanos . . . . . . . . . . . . . . . . 189 C.6. Traza de funcionamiento del acumulador . . . . . . . . . . . . . . . 191 C.7. Elección de tipo de llegada en una tarea . . . . . . . . . . . . . . 196 D.1. Estructura de evento VESPA implementada . . . . . . . . . . . . . 211 D.2. Tamaño mínimo y máximo de envío en red (servidor → cliente) segúntipodeelemento.........................233 xv xvi Índice de algoritmos B.1. Game loop ................................134 B.2.Bucledelactor .............................138 B.3. Método actualizar delactor ......................138 D.1. Detección de un evento . . . . . . . . . . . . . . . . . . . . . . . . . 212 D.2. Recepción de un evento . . . . . . . . . . . . . . . . . . . . . . . . . 214 D.3. Hilo de ejecución del gestor de almacenamiento . . . . . . . . . . . 215 D.4. Hilo de ejecución del procesador de consultas continuas . . . . . . . 215 D.5. Métodos del protocolo de reserva . . . . . . . . . . . . . . . . . . . 217 D.6. Obtención del vector dirección . . . . . . . . . . . . . . . . . . . . . 219 D.7. Estructura del servidor dedicado . . . . . . . . . . . . . . . . . . . . 224 D.8. Estructura del servidor de recogida de estadísticas . . . . . . . . . . 226 D.9. Estructura del hilo que maneja la conexión (Statistics server) . . . . 226 xvii xviii Capítulo 1 Introducción En este capítulo se mostrará la motivación existente para la realización de este Proyecto Fin de Carrera, los objetivos que han sido marcados para el proyecto, las librerías y herramientas utilizadas para su elaboración y también se analizará el trabajo relacionado. Finalmente se mostrará la estructura seguida en este documento. 1.1. Motivación del proyecto Han sido varias las razones que me llevaron a elegir desarrollar este Proyecto Fin de Carrera. La primera y principal ha sido el interés personal en el ámbito del desarrollo de videojuegos, que siempre me ha apasionado. Por otro lado, realizar un proyecto complejo como es un videojuego, partiendo desde cero y sin tener ningún conocimiento particular de este ámbito, suponía un gran reto que deseaba afrontar porque me permitiría ampliar mis conocimientos en campos diversos como inteligencia articial, arquitecturas y optimizaciones de red, etc., de las que poseía unos conocimientos limitados. Además, consideré que la experiencia que me podía aportar este proyecto aumentaría mis posibilidades de desarrollar mi carrera profesional en este ámbito. 1.2. Objetivos El Proyecto Fin de Carrera que se describe en este documento tiene los siguientes objetivos: Desarrollar un videojuego de coches, que cuente con coches controlados por el ordenador y otros controlados por jugadores humanos conectados a través de la red. 1 Desarrollar lo necesario para que se compita en escenarios creados a partir de datos reales obtenidos de algún sistema que proporcione mapas de carreteras. Desarrollar una funcionalidad de descarga de mapas, de forma que introduciendo la localización en la que deseas jugar se descargue una porción de mapa alrededor del punto elegido. Integración de los mecanismos de funcionamiento básicos de VESPA, de forma que el videojuego desarrollado permita la evaluación de las ventajas de contar con este sistema frente a un competidor que no lo tenga. La integración se realizará de forma que resulte sencillo modicar el funcionamiento de VESPA para evaluar el impacto de los cambios. Además de estos objetivos marcados por la propuesta del Proyecto Fin de Carrera, también se ha tenido como objetivo lograr que el resultado sea un juego divertido, con un nivel de dicultad moderado, de forma que no suponga un problema para los jugadores más inexpertos pero que a la vez pueda llegar a suponer un reto para los jugadores experimentados, y que pueda lograr despertar el interés por seguir jugando de los usuarios que lo prueben. 1.3. Trabajo previo y herramientas En esta sección se listan las librerías externas y herramientas utilizadas para el desarrollo del proyecto, acompañadas de una breve descripción del porqué de su uso. Código externo Para la implementación de la inteligencia articial del manejo de vehículos se han adaptado varios algoritmos contenidos en la librería OpenSteer (Steering Behaviors for Autonomous Characters) 1 , en la cual se hayan implementaciones de varios de los métodos sugeridos en [17]. Concretamente los métodos de esta librería adaptados son los siguientes: Obstacle avoidance , Path following , Unaligned collision avoidance y Wander . Librerías usadas Para el desarrollo del proyecto se ha hecho uso de diversas librerías externas que han permitido la implementación en un tiempo razonable de ciertas funciones necesarias que no formaban parte de los objetivos del proyecto: 1 http://opensteer.sourceforge.net/ 2 Apache Xerces2 java 2 , para el análisis y extracción de datos de los documentos XML obtenidos del servicio OpenStreetMap. JLayer 3 , para poder decodicar y reproducir sonido en MP3. Necesario para que la música de fondo pueda tener un tamaño reducido. Guava-12.0 4 , conjunto de librerías de Google de la que hago uso de su clase ImmutableMap . Herramientas de desarrollo Durante el desarrollo de este Proyecto Fin de Carrera se han utilizado las siguientes herramientas: NetBeans IDE 6.8 , como editor de código y ha sido especialmente bene- ciosa la ayuda que proporciona para elaborar interfaces grácas. Subversion , como herramienta de control de versiones. ClockingIT , como herramienta de gestión de tareas del proyecto. GIMP 2 , editor gráco usado para la elaboración de elementos grácos de los menús y para la creación y/o edición de los sprites de los elementos del juego. Audacity , editor de audio usado para la edición de los efectos de sonido del juego. Oracle VM VirtualBox , herramienta de virtualización usada para virtualizar el sistema operativo Mac OS X y poder realizar pruebas para asegurar la compatibilidad del juego. CamStudio 2.7 y Adobe Premiere Pro CS4 , herramientas de captura y edición de video usadas para la creación del video de la página web realizada para el proyecto. Java VisualVM , herramienta en la que se muestra información detallada de las aplicaciones java en funcionamiento, usada para analizar las mejoras de rendimiento que se introducían y analizar cuáles eran las partes del código que más afectaban al rendimiento. 2 http://xerces.apache.org/#xerces2-j 3 http://www.javazoom.net/javalayer/javalayer.html 4 https://code.google.com/p/guava-libraries/ 3 Netem , herramienta que proporciona funcionalidades de emulación de redes para probar protocolos y emular las propiedades de WANs 5 . Usada para simular un entorno de internet o WAN para realizar pruebas mientras se implementaban las técnicas de optimización de red. Herramientas de documentación Además de las anteriormente citadas, también se han usado las siguientes herramientas para la elaboración de la documentación del proyecto: L A TEX , lenguaje usado para la elaboración de este documento. Visual Paradigm for UML 6.4, Microsoft Visio 2010 y Dia , editores de diagramas. 1.4. Trabajo relacionado La idea de beneciarse de acciones humanas para mejorar o evaluar sistemas se ha aplicado previamente en otros videojuegos, como por ejemplo: ESP game [23], en el cual los jugadores ayudan implícitamente a etiquetar imágenes mientras juegan. CodeSpells [8], un videojuego de fantasía en el que los jugadores deben escribir hechizos sirviéndose del lenguaje Java Planet PI4 [14], un juego multijugador online que pretende servir para probar arquitecturas P2P para juegos. Sin embargo aparentemente este es el primer juego que será diseñado para ayudar a evaluar estrategias de gestión de información para redes vehiculares. Un juego similar en concepción en cuanto que también permite circular por escenarios reales es Mini Maps 6 , pero en dicho juego se pinta la vista de satélite de google maps y se superpone el vehículo, en lugar de crear un escenario a partir de la información del mapa. Otro juego, Push-Cars 2: On Europe Streets 7 también usa escenarios reales, pero la diferencia es que no se puede jugar en cualquier localización deseada ya que los escenarios están prejados ya que, aunque a partir de datos reales, están prediseñados de antemano. 5 http://www.linuxfoundation.org/collaborate/workgroups/networking/netem 6 https://apps.facebook.com/minimaps/ 7 http://www.push-cars.com 4 1.5. Estructura de la memoria El contenido de la memoria está distribuido de la siguiente forma: En el capítulo 2 se expone el trabajo desarrollado para la elaboración del juego, excluyendo lo realizado para el sitio web o la explotación. En el capítulo 3 se analiza la posible explotación del juego como método para probar diferentes técnicas de data sharing y se expone el trabajo realizado para permitirlo. También se muestra el rendimiento obtenido del videojuego. En el capítulo 4 se muestran las conclusiones del proyecto, el posible trabajo futuro de cara a mejorar el juego o la explotación y una breve valoración personal. Respecto al contenido de los anexos: En el anexo A se muestra todo lo referente al análisis realizado. En el anexo B se muestra todo lo relacionado con la fase de diseño. El anexo C contiene aspectos sobre el desarrollo del videojuego que no han podido ser tratados en el capítulo 2 o han sido tratados de forma resumida. En el anexo D se detalla el funcionamiento y la implementación del sistema VESPA y todos los aspectos desarrollados para el uso del videojuego como método de evaluación. También se amplía la información sobre el rendimiento del juego. El anexo E contiene el artículo presentado para el workshop IMMoA'13 , realizado conjuntamente con Sergio Ilarri y Eduardo Mena (en inglés). En el anexo F se proporciona el manual de usuario. 5 3. Las opciones globales, donde se controla el volumen, se pueden modicar los controles y cambiar la carpeta en la que se guardan los archivos de conguración del juego. También se han creado dos tipos de pantallas de error, que aparecen antes de la pantalla con el resumen de la partida. La primera se usa en errores durante la partida, y en ella se imprimen las diferentes trazas de error diferenciadas por pestañas según el elemento que las haya causado. La otra pantalla de error está dedicada para errores al intentar conectar a una partida, y su texto se modica dinámicamente dependiendo del tipo de problema. Las modicaciones de los parámetros realizadas en los menús y los nuevos escenarios descargados perduran entre diferentes ejecuciones de la aplicación gracias a que se almacenan en un directorio elegido previamente por el usuario y se cargan al inicio de la aplicación. La pantalla de gestión de mapas permite previsualizar cualquier área, descargada o no, tarea que se realiza obteniendo de una API la imagen en la que se representa el área seleccionada. Para no tener que pedir una nueva imagen cada vez que se varíe el tamaño seleccionado, se descarga con el tamaño máximo permitido en el juego y, mediante una función de recorte, se muestra únicamente el área proporcional al tamaño elegido. Para más detalles sobre estos aspectos consultar el anexo C.1. 2.4. Obtención de mapas Uno de los objetivos principales del proyecto consiste en la posibilidad de competir en escenarios reales. Esto se ha conseguido mediante el uso de los mapas proporcionados por el servicio OpenStreetMap 2 y del servicio de búsqueda OpenStreetMap Nominatim Tool 3 , que permite buscar coordenadas a partir de nombres o direcciones. La obtención y gestión de estos mapas se realiza desde el menú de la aplicación, obteniendo los datos mediante una de las APIs de OpenStreetMap. Para garantizar la obtención de los datos, en lugar de hacer uso de una única API, se dene una lista de APIs, modicable por el usuario, que serán usadas en orden secuencial hasta que una de ellas esté operativa. 2 http://www.openstreetmap.org 3 http://nominatim.openstreetmap.org 12 El proceso de la obtención de un mapa se ha implementado de la siguiente forma: 1. Se hace una petición al servicio OpenStreetMap Nominatim Tool con las palabras clave de la dirección deseada, y éste devuelve un listado de los lugares coincidentes. Cada lugar incluye, entre otros datos, el nombre y las coordenadas. 2. Una vez seleccionado el lugar deseado, se hace una petición al API de OpenStreetMap, pidiendo el área creada mediante las coordenadas devueltas el listado y el valor del radio deseado. El API devolverá un documento con formato OSM XML 4 que contendrá los datos requeridos, y que será el que se almacene en el directorio habilitado a tal efecto. Los mapas descargados se muestran en una tabla en la que además del alias asignado se incluye la dirección en torno a la cual esta creado, el número de nodos 5 que incluye y el tamaño del área en km2 . Estos mapas y sus previsualizaciones son almacenados para que no sea necesario volverlos a descargar cada vez que se inicie el programa. De esta forma, es posible jugar a Vanet-X aun sin tener conexión a internet, solo siendo necesario tener los mapas descargados en la carpeta correspondiente. Las previsualizaciones de los mapas que se han buscado pero no descargado también son almacenados pero éstos solo durante la ejecución del programa. Para más detalles sobre estos aspectos consultar el anexo C.2. 2.5. Elementos del terreno Como se ha explicado anteriormente (Capítulo 2.4), los datos necesarios para crear los escenarios son obtenidos del servicio de mapas OpenStreetMap. Existen tres tipos de elementos: nodos, caminos y multipolígonos. Los caminos están formado por nodos y los multipolígonos están formados por caminos. De estos elementos, los nodos son los únicos que no tienen representación visual, usándose solo para formar el resto de elementos. Los caminos y multipolígonos se organizan en diferentes capas de profundidad de pintado según su etiqueta (es decir, según sean calles peatonales, zonas residenciales, carriles bici, etc.). Un lugar de interés es un nodo que tiene dos datos adicionales: una lista con los tres aparcamientos más cercanos y el valor de la distancia existente desde el nodo 4 http://wiki.openstreetmap.org/wiki/OSM_XML 5 un nodo es el menor de los datos primitivos que conforman un mapa de OpenStreetMap 13 hasta el camino más cercano transitable por los jugadores. Es un concepto introducido para permitir los objetivos de tipo tarea en los modos de juego resolver tareas y supervivencia. Todos los elementos constan de un identicador y las etiquetas obtenidas de OSM, y a excepción de los nodos, también la capa en la que se pintarán. Además, cada tipo de elemento está formado por más campos: Nodo : tiene una posición expresada en pixeles que es el resultado de la conversión de las coordenadas WGS84 a UTM y éstas a su vez a las del sistema del juego. También posee dos listados con los nodos con los que está directamente conectado, uno con los nodos que son accesibles con las reglas de tránsito de los vehículos enemigos y otro con las de los vehículos del tráco, y un tercer listado que contiene la distancia a otros nodos no directamente conectados, que se va rellenando dinámicamente durante la ejecución y sirve para evitar la repetición de ciertos cálculos (ver Anexo G.4 y Figura G.1). Estos cálculos de nodos interconectados se pueden realizar gracias a que también contiene un listado con los identicadores de los caminos en los que está incluido este nodo. Camino : cuenta con un listado de los nodos que componen el camino y una lista con los segmentos rectos entre los nodos. Estos segmentos se utilizan no solo para el pintado sino también para detectar si los vehículos están sobre el camino. También se incluyen diversos parámetros con propiedades para la circulación y el pintado. Al igual que los lugares de interés , también incluye una lista con los tres aparcamientos más cercanos. Multipolígono : dependiendo de la implementación usada (ver Anexo C.3.3) contiene una estructura que permite que cada camino formante del multipolígono tenga un rol denido (anillo interior o exterior del área) o un polígono representando el área. Además, en ambas implementaciones también existen diversos parámetros con las propiedades del terreno. En el anexo C.3 se explican con mayor detalle todos estos aspectos. 2.6. Física Debido a la simpleza de las físicas necesarias para un juego de este tipo, que no requiere un gran realismo, no se consideró necesario utilizar un motor de física 14 existente sino que se tomó la decisión de implementar personalmente las funciones que se consideraron necesarias. El sistema de físicas implementado puede dividirse en cuatro algoritmos: la detección de colisiones y la aplicación de fuerzas resultantes de la colisión, ambos de forma diferenciada para colisiones con el terreno y con los actores. La detección de colisiones con el terreno consiste en recorrer todos los elementos que conforman el terreno 6 y para cada uno de los elementos se realiza el siguiente proceso: Se comprueba si la menor circunferencia capaz de contener al vehículo colisiona con el menor rectángulo capaz de contener al elemento. Si esta comprobación devuelve como resultado que no hay colisión, se puede asegurar con total abilidad y el coste de procesamiento que ha supuesto es muy bajo. Sin embargo, si devuelve lo contrario, signicaría que es posible que exista colisión y para averiguarlo se debe realizar una segunda comprobación, más costosa, que comprueba si alguno de los cuatro vértices del vehículo está en el interior del elemento del terreno. La aplicación de dicha colisión consiste en reconocer las propiedades del terreno sobre el cual se circula y aplicar las restricciones correspondientes al vehículo: inmovilizarlo, ralentizarlo, dañarlo, etc. En los anexos C.4.1 y C.4.4 se encuentra una explicación más detallada al respecto. La detección de colisiones con los demás actores del juego se realiza de una forma similar: Se obtiene el menor rectángulo rotado capaz de contener al vehículo, y se comprueba si colisiona con el de algún otro actor. Si se produce esa colisión, signica que es posible que realmente colisionen, y se realiza una segunda comprobación más detallada aplicando el Separating Axis theorem 7 . En el anexo C.4.2 se encuentra una explicación más detallada al respecto. Para calcular el resultado de una colisión entre actores primero se debe calcular la fuerza resultante de suma de las fuerzas de los dos vehículos implicados. Esto se calcula con el siguiente algoritmo: 1. Se obtienen los vectores velocidad de los dos implicados. Ver Figura 2.5(a) 2. Se realiza una rotación de forma que la línea imaginaria entre los dos implicados quede en el eje Y. Ver Figura 2.5(b) 6 como se explica en el apartado 4.3, una mejora importante sería dividir el terreno en una cuadrícula y solo comprobar los elementos de su zona 7 http://en.wikipedia.org/wiki/Hyperplane_separation_theorem#Use_in_collision_ detection 15 V2 Vy2 V2 V1 V2 V1 Vy1 Vresultado V1 (a) (b) (c) (d) Figura 2.5: Etapas del cálculo del vector fuerza resultante de una colisión 3. El vector resultado (provisional) es la componente Y del vector velocidad del propio vehículo, salvo que se trate de un choque por alcance en cuyo caso se le debe restar la componente Y del vector del otro vehículo. Ver Figura 2.5(c) 4. Para asegurar que no se genere una fuerza de atracción cuando el vector está en sentido opuesto al otro implicado (sentido negativo de la Y ), se debe asegurar que el valor resultado nunca será mayor a -1 (se ha elegido este valor en lugar de 0 para asegurar que siempre exista fuerza de repulsión entre los coches). 5. Se vuelve a rotar el vector resultado invirtiendo la rotación realizada en el paso 2. Ver Figura 2.5(d) Esta fuerza resultante es sumada a la del otro vehículo, salvo que aquel se encontrase en estado inmóvil, en cuyo caso en su lugar esa fuerza sería restada a la del vehículo propio. Posteriormente se establece la velocidad del propio vehículo a cero. 2.7. Inteligencia articial En Vanet-X , como cualquier otro juego en el que intervengan actores no controlados por jugadores, se necesita una inteligencia articial que sea capaz de controlar estos actores. En el caso de este juego, los actores que requieren de una inteligencia articial son los coches enemigos, las ambulancias y los coches neutrales que conforman el tráco del escenario. Como todos estos actores son vehículos, todos ellos comparten gran parte de las funciones desarrolladas para la inteligencia, siendo sus diferencias solo pequeñas variaciones en los comportamientos. La inteligencia desarrollada consta de tres partes: 16 Unos patrones de comportamiento de alto nivel, en forma de máquina de estados, que indiquen las acciones a realizar en cada momento. (Por ejemplo: buscar aparcamiento, huir del jugador, alcanzar un punto determinado...). Unos patrones de manejo de la dirección del vehículo, de forma que indicando un objetivo y un modo de conducción (huir, perseguir, alcanzar...) el vehículo sea capaz de lograrlo sin salirse de las zonas permitidas para circular y sin colisionar contra otros vehículos o elementos jos del terreno. Un algoritmo de búsqueda A* capaz de determinar el camino a tomar para llegar de un punto a otro, teniendo en cuenta las diferentes restricciones de paso que tienen los diferentes vehículos. Cada una de las partes hace uso de la siguiente, es decir, los patrones de comportamiento de alto nivel usan patrones de manejo de la dirección, y éstos a su vez usan el algoritmo A* del path-nding . Para profundizar en más detalle en cada uno de las tres partes anteriormente mencionadas, dirigirse al anexo C.5. 2.7.1. Comportamiento de los vehículos Cada vehículo dotado de inteligencia propia posee unos patrones de comportamiento que indican que tipo de acciones realizarán. Estos patrones dieren según el tipo de vehículo y se componen de combinaciones de steering behaviors , comportamientos de bajo nivel explicados en la siguiente subsección. En esta subsección se analizará únicamente el comportamiento de los vehículos del tráco y un movimiento común a todos los vehículos: desatascarse, debiéndose consultar el anexo C.5.2 para el resto de tipos de vehículos. Desatascarse se trata de salir marcha atrás de una posición en la que se encuentra inmovilizado. Este comportamiento es necesario ya que a pesar de los esfuerzos por mejorar la inteligencia de los vehículos, es común que por diversos motivos un vehículo pueda acabar estrellado contra los márgenes de la carretera, en cuyo caso no podrá seguir avanzando ya que no está permitido salirse de las vías habilitadas. Este comportamiento establece como objetivo un punto situado a una distancia determinada justo detrás del vehículo y hace que avance hacia él en marcha atrás. Una vez se ha conseguido llegar al objetivo (y por lo tanto se ha desinmovilizado), el comportamiento pasa a estado normal. 17 Circular Aparcar Esperar aparcado Hay menos coches de los establecidos buscando aparcamiento Tiempo para encontrar aparcamiento excedido Ves un parking libre El parking obje!vo estaba ocupado o se ha excedido el !empo para aparcar en él Aparcas en el parking Tiempo de espera excedido Buscar aparcamiento Figura 2.6: Detalle del estado Normal de la inteligencia de los vehículos del tráco Tráco: Como se muestra en la Figura 2.6, tiene cuatro posibles subestados: Circular : consiste en elegir un nodo objetivo y alcanzarlo. Este estado se repite hasta que al vehículo le llegue una señal que indique que hay menos coches buscando parking de los establecidos. Ver Figura C.19 en el anexo C.5.2. Buscar aparcamiento : es el mismo comportamiento que el anterior pero ahora buscando aparcamientos vacíos. De esta forma si se visualiza un aparcamiento libre pasará al siguiente estado ( Aparcar ), mientras que si en un tiempo establecido no se ha logrado visualizar ninguno vuelve al estado anterior ( Circular ). Además, si se recibe un evento VESPA de parking libre se dirige a la posición del evento (aunque por el camino puede encontrar otro aparcamiento libre más cercano y aparcar en él). Aparcar : consiste en realizar la maniobra de aparcamiento sobre el aparcamiento libre objetivo. Se realiza mediante un comportamiento de llegada para que el vehículo frene al aparcar. Si se logra aparcar se avanza al siguiente estado ( Esperar aparcado ) mientras que si no se ha logrado se retrocede al estado anterior. Esperar aparcado : consiste en esperar quieto dentro de la plaza de aparcamiento durante un tiempo determinado. Una vez completado ese tiempo se vuelve al estado inicial ( Circular ). 2.7.2. Aplicando Steering behaviors El manejo de la dirección del vehículo ha sido realizado mediante el uso de los steering behaviors : comportamientos que permiten a los agentes autónomos navegar por su entorno de una manera improvisada a la vez que realista [17]. 18 Para este proyecto se han implementado los siguientes comportamientos sugeridos en [17]: seek , ee , pursuit , evasion , arrival , obstacle avoidance , wander , path following y unaligned collision avoidance . Estos comportamientos son explicados en detalle en el Anexo C.5.1. Estos comportamientos se pueden combinar entre sí para crear comportamientos más complejos. Esta combinación de comportamientos se ha realizado según el siguiente método: Se le asigna una prioridad a cada comportamiento y se evalúan uno a uno en orden de prioridad. Si un comportamiento concluye que debe realizarse una corrección de la dirección, se aplica esa corrección y se acaba el comportamiento. En caso de que no sea necesario un ajuste de la dirección, se evalúa el siguiente comportamiento, y así sucesivamente hasta encontrar un comportamiento que requiera un cambio de dirección o hasta haber evaluado todos. Un ejemplo de esta combinación es el comportamiento que se le aplica a las ambulancias: Primero, trata de no salirse de la carretera ( path following ). Si este comportamiento evalúa que no son necesarios cambios, trata de no colisionar contra obstáculos jos ( obstacle avoidance ) primero, ni móviles ( unaligned collision avoidance ) después. Finalmente, si ninguna corrección ha sido necesaria, trata de avanzar hacia el objetivo ( seek ). 2.7.3. Búsqueda de caminos La última de las tres partes en las que se divide la implementación realizada de la inteligencia articial es el path-nding (búsqueda de caminos), que es el encargado de, a partir de un grafo de nodos que contiene la estructura de las calles, un nodo inicial y un nodo objetivo, devolver una lista ordenada de nodos que permitan alcanzar el nodo objetivo. Como la obtención del resultado usualmente tarda más que el tiempo de ciclo del juego, la implementación se ha realizado de forma asíncrona, con un hilo de ejecución dedicado en exclusiva a recibir peticiones, ejecutar el algoritmo y devolver su resultado cuando esté listo (ver Figura 2.7). De esta forma, los actores que hayan pedido un camino, en lugar de realizar la petición y esperar bloqueados a la respuesta, comprueban en cada ciclo si ya está lista, y en caso contrario, en lugar de no hacer nada, lo cual quedaría muy extraño, siguen avanzando hacia el objetivo mediante el steering behavior de llegada, de forma que para cuando obtengan la respuesta del path-nding, generalmente se habrán aproximado más al objetivo. 19 Lógica del actor - Esperar una pe!ción - Calcular camino - Almacenarlo en buffer Buffer Pedir camino Esperar a los datos Responder Path-finding Actor Hilo actor Hilo path-finding Figura 2.7: Path-nding asíncrono 2.8. Funcionamiento en red Como se ha explicado anteriormente, la arquitectura de red de este proyecto está basada en el modelo de red del Quake3 [13], que fue un gran éxito debido a su simplicidad y a la facilidad de entenderlo. Los modelos de red de muchos juegos posteriores son muy similares o están basados en este, como por ejemplo juegos superventas como Half-life (más conocido por su modicación CounterStrike ), y su secuela, que usa el modelo de red del Source Engine [22], el cual también ha sido tomado como referencia para crear la arquitectura de red de este proyecto. Las ideas obtenidas del estudio de estos dos modelos son las siguientes: seguir una estructura cliente-servidor con predicción en el lado del cliente [2, 12, 10, 18] usar compresión delta sobre el último estado conocido, para reducir el tamaño de los paquetes enviados [13] interpolación/extrapolación de las entidades, de forma que se prevengan los saltos cuando no se reciban paquetes de red [22]: Una vez que estas ideas estaban claras, el siguiente paso fue elegir el protocolo de red que usaría la aplicación. En un juego que necesita actualizaciones de estado en tiempo real es importante que los datos lleguen lo más rápido posible, y no necesitamos que se reenvíen los paquetes perdidos ya que al reenviarlos ya llegarían obsoletos y tendríamos que desecharlos. Es por este motivo que los modelos citados anteriormente usan el protocolo UDP, el cual tiene un mejor rendimiento a costa de no implementar características que si poseen TCP y RMI [21, 12]. En este proyecto, se ha considerado que además de usar UDP para las actualizaciones de estado, se podría combinar con el uso de TCP para ciertas tareas que no requieren velocidad de transmisión y sí conabilidad. Por lo tanto, se han usado conjuntamente los protocolos UDP y TCP de la siguiente manera: 20 UDP se ha usado para las actualizaciones de los estados que se envían en cada ciclo. TCP se ha usado para el envío del estado inicial al cliente, también para comunicaciones con clientes que todavía no se han unido al juego (cuando se quieren unir a la partida, reunir información o recibir las estadísticas nales) y para ciertos eventos poco comunes que se envían al cliente (como por ejemplo actualizaciones de la puntuación o mensajes que informan de logros nuestros o de otros jugadores 8 ). Para mejorar la experiencia de juego, se han implementado varias técnicas que aumentan la uidez con las que el usuario percibe que funciona el juego. Se trata de la predicción en el lado cliente y de la interpolación de las entidades. 2.8.1. Modelo de red Al igual que en los modelos estudiados, se ha seguido un esquema clienteservidor, ya que en un juego en tiempo real donde deben enviarse múltiples mensajes de estado por segundo, un esquema alternativo Peer-to-peer , donde cada cliente envía información a todos los demás, es inviable salvo en conexiones extremadamente rápidas como redes locales [10]. Concretamente el modelo elegido es cliente-servidor con servidor autoritativo, lo que signica que el servidor es el único capaz de tomar decisiones que afecten al estado del juego, dejando al cliente básicamente como un terminal tonto cuyas únicas funciones son recoger los comandos del jugador, transmitirlos al servidor, y con los datos de su respuesta pintar el mundo de juego (aunque con la técnica de la interpolación gana más funciones). La razón de esto es que si fuera el cliente el encargado de realizar las simulaciones y enviarle al servidor su estado, como por ejemplo su posición actual, sería demasiado fácil que alguien hiciera trampas logrando que el cliente envíe al servidor datos falsos. [10] La lógica básica del cliente y el servidor es la siguiente: Al inicio de cada ciclo los clientes envían al servidor los comandos realizados por el jugador, el servidor procesa estos comandos, genera el estado del mundo de juego de esta secuencia o ciclo y lo reenvía al cliente, que con estos datos pinta su vista del mundo de juego. Concretamente el intercambio de mensajes entre cliente y servidor es el siguiente (Ver Figura 2.8): El cliente envía InputSnapshots que contienen los eventos de teclado, el identicador de jugador al que corresponden, y los siguientes datos de control: 8 Vease lo referido a Mensajes GUI en el Capítulo 2.13 21 Existen cuatro clases que implementan la interfaz IObjetivos, una por cada modo de juego, adaptando las funciones denidas para crear la mecánica de juego deseada en cada modo. Para los modos de juegos que no consisten en capturar banderas o vehículos sino en completar objetivos, se ha creado una nueva estructura llamada Tarea (ver anexo C.7.1), que incluye todos los datos requeridos de un objetivo: tipo de lugar, tipo de llegada y distancia al primer y tercer aparcamiento más cercano. También debido a las necesidades de estos modos se han incluido las plazas de aparcamiento (ver anexo C.7.2) y la posibilidad de abandonar el vehículo (ver anexo C.7.3). Por último existe una clase destinada a contener todas las características de los modos de juego, como por ejemplo: el tipo de objetivo de una ronda (banderas, enemigos, tareas), el comportamiento de la inteligencia de los enemigos (perseguir, huir), si los jugadores sufren daños, etc. 2.13. Mensajes durante el juego Durante la partida, existen varios medios con los que el jugador recibe información. Estos son los mensajes GUI y la explicación de la ronda . Los mensajes GUI son un sistema mediante el cual se le suministra al jugador información sobre ciertos eventos relevantes como por ejemplo: la unión de un nuevo jugador a la partida, los puntos obtenidos por lograr un objetivo, el dinero que ha costado la reparación del vehículo, un logro de otro jugador, y muchas otras más. Estos mensajes están visualmente muy integrados de forma que no molestan en la conducción pero a la vez son fáciles de percibir. Además, con el sistema desarrollado, cada evento puede denir su duración en pantalla y esta asegurado que en caso de acumularse varios mensajes no se superpondrán sino que mantendrán su orden y se irán mostrando uno a uno dejando un breve lapso de tiempo entre cada uno para que el cambio de mensaje sea perceptible. La explicación de la ronda es un sistema que muestra información sobre la ronda actual. Esto es totalmente necesario ya que, como se ha mencionado anteriormente, el sistema de juego funciona mediante un sistema de rondas continuas sin abandonar la partida para volver a los menús. Por lo tanto resulta necesario un sistema que muestre durante la partida la información que necesita conocer el jugador. Esta información depende del modo de juego elegido pero tiene varios elementos comunes: el número de ronda en la que nos encontramos y el número total de rondas en caso de que exista un límite, el número de perseguidores enemigos, el tiempo disponible para completar la ronda, los objetivos de la ronda. 28 Esta explicación se muestra durante el llamado tiempo entre rondas 14 incluyendo una cuenta atrás del tiempo restante antes de comenzar la siguiente ronda. También se muestra parecida información (más resumida) pulsando en cualquier momento de la partida la tecla Mostrar información (por defecto tecla Q). Todo esto se muestra en una zona rectangular semitransparente ubicada en la zona central superior de la zona de juego. Esta zona adapta dinámicamente su tamaño según los datos que deba mostrar. En la gura 2.14 se muestra una captura del juego en la que se aprecia la explicación de la ronda (zona superior, en texto amarillo) y un mensaje GUI (en texto blanco en la zona inferior). Figura 2.14: Captura de pantalla en la que se muestra la explicación de la ronda y un mensaje GUI 14 congurable desde la pantalla Conguración de las reglas de juego 29 30 Capítulo 3 Explotación En esta sección se analiza la explotación del juego como método para probar diferentes técnicas de data sharing y se expone el trabajo realizado para permitirlo, así como las ventajas y limitaciones existentes. 3.1. Motivación Los análisis de diferentes técnicas de data sharing suelen realizarse mediante el uso de simuladores (p.ej. TraNS [16], SUMO [1], Veins [20], GrooveNet [15], o VanetMobiSim [11]) ya que realizar pruebas en un escenario real con un número signicativo de vehículos sería un método caro y poco práctico. Aún con el uso de simuladores, el análisis de estas técnicas puede seguir siendo una tarea ardua que lleve mucho tiempo, ya que los resultados de muchas técnicas de data sharing dependen de la elección de ciertos parámetros, y puede no ser fácil determinar cuál sería una buena elección de estos parámetros. Por este motivo se ha considerado que, de forma complementaria al uso de simuladores, se podría aplicar una estrategia de crowdsourcing mediante el uso de este juego de forma que se extraigan ciertas estadísticas de las partidas y los jugadores, mientras se divierten con un juego de coches, estén en realidad ayudando a calibrar estrategias de data sharing . La idea de beneciarse de acciones humanas para mejorar o evaluar sistemas no es nueva, ya que se lleva tiempo usando para tareas demasiado costosas usando los métodos tradicionales. Ejemplos de esto serían mCrowd [25], que usa los sensores de los smartphones para participar en tareas colaborativas como la monitorización del tráco de carreteras, o reCAPTCHA [24], que se utiliza para evitar el uso de ciertos servicios por usuarios no humanos a la vez que sirve para mejorar la digitalización de textos. 31 3.2. Aplicación Para llevar a cabo la recolección de estadísticas durante la partida se han habilitado varias opciones (en el chero de texto de conguración ParamCong.txt ) que habilitan y deshabilitan de forma individual la recolección de distintos tipos de datos. Estos tipos de datos que se recopilan son los siguientes (ver Anexo D.2.3 para los detalles las estadísticas recogidas): Estadísticas del juego: son las estadísticas que se muestran a los jugadores al nalizar la partida y comprende la puntuación de cada jugador, equipo al que pertenece y estado (habilitado o deshabilitado) de su protocolo DMS ( Data Management Strategy ). Estadísticas de los aparcamientos: se muestra cada aparcamiento realizado, tanto por jugadores como por vehículos del tráco, incluyendo el tiempo requerido, el identicador del vehículo que lo realiza, si dicho vehículo tenía el protocolo DMS activado, con que tipo de protocolo contaba y si dicho aparcamiento fue facilitado por el uso del DMS . Estadísticas del protocolo VESPA: muestra de forma individualizada por vehículo, y también de manera conjunta, diversas estadísticas relacionadas con el funcionamiento y la eciencia del protocolo (p.ej. número de eventos creados, porcentaje de eventos considerados relevantes, etc.). Cuando la partida naliza, estos datos recogidos se almacenan en cheros en el computador donde reside el servidor junto con un chero que contiene la información sobre todos los aspectos de la conguración de la partida, de forma que a partir del contenido de este chero sea posible congurar una nueva partida con las mismas condiciones. Este almacenamiento se realiza únicamente en la máquina servidor y no en los clientes ya que los jugadores no tienen porqué tener interés en estos datos. Al realizarse esta recopilación de datos únicamente en el servidor, en el caso de crearse múltiples partidas en diferentes computadores sería necesario recopilar de forma manual las estadísticas producidas. Para evitar esto, se han ideado dos sistemas que permiten un mayor control sobre las estadísticas: la creación de un servidor de recogida de estadísticas y la creación de un servidor dedicado. El servidor de recogida de estadísticas es un proceso que está en permanente ejecución en un computador externo, y al que los servidores se conectarán al nalizar las partidas con la nalidad de transmitirle las estadísticas recopiladas durante la partida. (Ver Anexo D.2.2) 32 El otro sistema ideado consiste en el uso del servidor dedicado (ver Anexo D.2.1), que consiste en un proceso en permanente ejecución en un computador y que acepta las peticiones de conexión de los clientes (realizadas de la misma forma que para unirse a una partida normal) y, en el caso de que no haya una instancia del servidor en funcionamiento, la crea y les redirige para que se unan a dicha partida. De esta forma, un desarrollador/probador de un protocolo DMS puede habilitar un lugar en el que los jugadores se puedan unir a una partida de forma que no necesiten crear partidas propias y centralizando así las estadísticas en dicho lugar. Estos dos sistemas son complementarios, de forma que el servidor dedicado al nalizar la partida tratará de conectarse con el servidor de recogida de estadísticas, si es que está activo, para comunicarle las estadísticas obtenidas. En la Figura 3.1 se muestra la forma en que los diferentes componentes del juego están distribuidos en la red. Computer Servidor Maestro Servidor (Juego) Estadís!cas Computer Cliente (Juego) Jugador n Pedir servidor al que unirte Conectarse al servidor Crear Guardar estadís!cas del juego Computer Servidor Estadís!co Estadís!cas Guardar estadís!cas del juego Enviar estadís!cas Computer Terminal Cambiar parámetros Y Conseguir estadís!cas Interesado en estadís!cas Computer Cliente (Juego) Jugador 1 Pedir servidor al que unirte Conectarse al servidor ... ... Figura 3.1: Despliegue de los componentes en una red 33 Además de estas características previamente mencionadas, se ha realizado la implementación de VESPA de forma que sea sencillo adaptar el juego para diversos protocolos o estrategias de gestión de datos. Esto se ha realizado deniendo las interfaces y clases abstractas básicas que se necesitan para poder interaccionar desde el juego con la DMS . Posteriormente se ha realizado una implementación del sistema VESPA como instanciación de dichos interfaces, haciendo uso del patrón de diseño Factory method (ver Anexo D.1 para más detalles). Las más importantes de las interfaces denidas son las siguientes: IDataManagementStrategy : declara los métodos que deben ser implementados por una DMS para permitir su integración con el videojuego. IVisible : debe ser implementada por todas aquellas entidades que puedan ser observadas por el DMS . IVehicle : debe ser implementada por todos los vehículos observables por el DMS . IPlayerVehicle : debe ser implementada por todos los vehículos humanos observables por el DMS . ITracVehicle : debe ser implementada por todos los vehículos del tráco observables por el DMS . Como se puede observar la primera interfaz es usada para que el juego se comunique con el DMS mientras que las cuatro restantes se usan para que el DMS pueda acceder a los datos de las entidades del juego. La gura 3.2 proporciona una visión de conjunto sobre la conexión entre el juego, las interfaces denidas y la implementación desarrollada. 3.3. Limitaciones El uso de un juego como método de análisis tiene diversas limitaciones, por lo que no se plantea su uso como reemplazo del simulador sino como complemento. Una es la dicultad de conseguir una simulación precisa y al mismo tiempo un juego divertido y jugable, ya que la inclusión de regulación semafórica, normas de circulación o tráco más realista supondría una mayor delidad en la obtención de resultados pero sin embargo podría alterar la dinámica del juego disminuyendo su capacidad de atraer jugadores y por lo tanto disminuyendo la cantidad de estadísticas que se podrían obtener. Así mismo tratar de aumentar la precisión de la simulación, ejecutar protocolos de gestión de datos complejos o tratar de simular una cantidad de tráco elevada está 34 Car Interface IVehicle Interface IDataManagementStrategy TrafficCar VESPA IEvent FactoryDMS VespaEvent Interface IVisible Interface IPlayerVehicle Interface ITrafficVehicle Actor Player Parking MiCanvasServidor SERVER-SIDE implementa es subclase de se comunica con usa Figura 3.2: Arquitectura de la la conexión entre el juego y el DMS 35 enfrentado con la obtención de un rendimiento aceptable en el juego (en número de fotogramas por segundo). Además otra dicultad radica en que los resultados obtenidos pueden depender de la pericia de los jugadores, por lo que comparar resultados sin tener este factor en cuenta puede conducir a conclusiones erróneas. Por este motivo es preciso comparar siempre resultados obtenidos con jugadores de similar pericia. Para solventar esta dicultad, se ha implementado un sistema de cálculo de habilidad, que otorga a cada jugador un determinado nivel de pericia basado en su rapidez completando misiones durante las partidas y se mide en tareas completadas por unidad de tiempo. Este nivel de pericia se va modicando mediante la participación en nuevas partidas y queda reejado en las estadísticas obtenidas, de forma que puede optarse por comparar solo resultados provenientes de jugadores de similar nivel de pericia. Adicionalmente, existe una opción (congurable en ParamCong.txt ) para no permitir unirse a tu partida a jugadores con menos de un determinado nivel de habilidad. 3.4. Ventajas Las ventajas que aporta este método de análisis son la introducción del componente humano, que es algo que no está presente en un simulador, y el hecho de que la utilización masiva del juego podría ayudar a identicar parámetros o alternativas de gestión de datos prometedoras que luego podrían vericarse por simulación. Además, en vista de los resultados obtenidos, a pesar de que los valores absolutos dieren de los obtenidos mediante el simulador, los valores relativos observados sí que son coherentes. 3.5. Elementos añadidos al juego Diversos elementos han sido añadidos al juego con el objetivo de facilitar la explotación del mismo como método de análisis de técnicas de data sharing : las plazas de aparcamiento, el modo de juego consistente en pruebas de aparcamiento y el cambio automático de estrategia de gestión de información. Se añadieron las plazas de aparcamiento, con el n de contar con un elemento más en el que medir la eciencia de las técnicas de data sharing usadas. Por motivos de rendimiento se crearon dos tipos de plazas de aparcamiento: las reales y las falsas. Las reales son plazas inicialmente vacías que los vehículos pueden ocupar y desocupar según sus necesidades, mientras que 36 las falsas son plazas que siempre están ocupadas y su inclusión viene determinada para aparentar visualmente la existencia de un gran número de aparcamientos, reduciendo la monotonía del escenario, sin necesitar aumentar el número de vehículos del tráco para que las ocupen y desocupen, con el coste computacional que ello supondría. Para evitar que el jugador sea capaz de distinguir entre los tipos de plazas, y por lo tanto sepa que plazas ocupadas se terminarán por desocupar y cuáles no, se han utilizado diversas técnicas. Como los vehículos del tráco no realizan aparcamientos perfectos, se tomó una doble estrategia: por un lado se evitó que las plazas falsas tuvieran una apariencia de aparcamiento perfecto, modicando el sprite que la representa de forma que el vehículo que se muestra aparcado esté ligeramente rotado y trasladado respecto a su posición ideal, y por otro lado, en lo referente a las plazas reales, se creó un método mediante el cual los vehículos mal aparcados en ellas son colocados de la forma correcta cuando no exista ningún jugador a menos de una determinada distancia que pueda observar la traslación cometida. Para poder obtener resultados comparables a los resultados del simulador de VESPA, se estableció un ratio jo entre el número de vehículos que buscan aparcamiento y el número de plazas existentes. Para conseguirlo, se programó la inteligencia de los vehículos del tráco de forma que haya siempre un número permanente de vehículos buscando aparcamiento y cuando uno de ellos logre aparcar, otro vehículo que estuviera simplemente circulando se ponga a buscar aparcamiento inmediatamente. El tiempo que un vehículo permanece aparcado no es constante y varía entre 20 y 40 segundos, los cuales son valores poco realistas pero que suponen un tiempo suciente como para que el jugador no se quede a la espera de que se libere una plaza ocupada y a su vez no son lo sucientemente grandes como para que en una partida corta apenas se produzcan liberaciones de aparcamientos. Se añadió un nuevo modo de juego ideado expresamente para conseguir medir los tiempos de aparcamiento, de forma que mediante objetivos se facilitase la toma de datos. Este modo de juego consiste en un sistema de objetivos en el que cada ronda tiene un doble objetivo que se debe cumplir de forma secuencial: primero ir a un punto establecido (dado mediante una dirección o mediante un sitio de interés) y una vez logrado este objetivo, encontrar aparcamiento cercano (a menos de una distancia establecida por defecto en 500m pero modicable en ParamCong.txt ). Cuando se logra el objetivo de aparcar, se avanza de ronda y se repite este esquema hasta lograr el número de rondas seleccionadas en la conguración de la partida. 37 Se pensó que sería una buena idea adaptar este juego ya que las banderas podrían representar eventos jos del sistema VESPA y los vehículos enemigos representarían eventos móviles. Sin embargo, se decidió modicar otros aspectos para adecuarlo al tiempo actual. De esta manera se cambió el control del vehículo de forma que ahora podría realizar giros de cualquier ángulo, pudiendo tomar una trayectoria más cerrada cuanto menos fuera la velocidad a la que circulase. Otra modicación fue sustituir el laberinto sobre el que se circulaba por escenarios reales obtenidos a través del sistema de mapas OpenStreetMap. Éstos fueron los objetivos de la primera iteración del juego. A continuación se muestra el trabajo realizado en las diferentes iteraciones: 1 a iteración : se tomó como base un tutorial de realización del clásico Space Invaders en Java 1 y la lectura del libro Developing Games in Java [4], lo cual aportó los conocimientos básicos sobre la estructura de un juego, el pintado o la inclusión de sonidos. La inteligencia articial usada para los vehículos enemigos era muy básica ya que se cometió el error de tratar de realizarla partiendo desde cero. 2 a iteración : consistió en añadir la capacidad de que participen varios jugadores a través de la red. Para ello se buscó información sobre las arquitecturas de red usadas habitualmente en videojuegos y se llegó a la conclusión de que una arquitectura del tipo cliente-servidor con predicción en cliente era la idónea, contando con la suerte de que este tipo de arquitectura era la más habitualmente utilizada y se disponía de suciente documentación al respecto proveniente de los juegos Quake3 y Half-Life , los cuales fueron los pioneros en usarla. Esta iteración fue una de las más costosas ya que a pesar de los artículos publicados al respecto, había aspectos insucientemente documentados. 3 a iteración : el objetivo fue convertir el juego, realizado hasta ahora con un único hilo de ejecución (exceptuando el sonido), en multi-hilo, de forma que cada actor tuviera su propio hilo de ejecución. Esto aparentemente entraba en conicto con la técnica de predicción usada en la arquitectura de red, pero sin embargo no fue así, ya que esa técnica se desarrollaba en el cliente, y en éste no tenía sentido una implementación multi-hilo de los actores ya que éstos no realizaban tarea alguna más allá del pintado. De esta forma se realizó una implementación multi-hilo en el servidor y de un único hilo (más 1 http://balusoft.wordpress.com/2010/09/26/creando-un-space-invaders-conjava/ 44 los del sonido) en el cliente, ya que este último no dejaba de ser un mero terminal de E/S con algunas capacidades extra. También se mejoró la representación visual, añadiendo nuevos tipos de terreno como diferentes tipos de caminos (utilizando los diferentes tipos existentes en OpenStreetMap) o los edicios, y se modicó el sistema de detección de colisiones con el terreno. 4 a iteración : como se ha mencionado anteriormente, la inteligencia desarrollada para el manejo de los vehículos no humanos era muy básica y nada extensible, por lo que el objetivo de esta iteración consistió en rehacer dicha inteligencia. Vistos los resultados del intento de realizar la inteligencia desde cero, se decidió usar los diferentes comportamientos desarrollados en el artículo Steering Behaviors For Autonomous Characters [17], que permitían construir comportamientos complejos a partir de ellos y consistían en una aproximación basada en la diferencia entre el vector de trayectoria del vehículo y el vector hasta el punto objetivo deseado. Fue en este momento cuando se vio la necesidad de añadir más vehículos controlados por el ordenador: los vehículos del tráco, que servirían para retransmitir los eventos VESPA además de para aportar más vida al escenario, y las ambulancias, como generador de eventos VESPA del tipo servicio de emergencia. 5 a iteración : hasta este momento el juego no contaba con un sistema de menús y al ejecutarlo ya comenzaba la partida en un mapa prejado que se había obtenido manualmente desde el sitio web de OpenStreetMap. Por ese motivo esta iteración consistió en dotar al juego de un sistema de pantallas de menú que permitiese congurar diversos aspectos de la partida y permitir un método de añadir nuevos escenarios desde dentro del propio juego. Para esto último, se desarrolló la estructura necesaria para el almacenamiento de los escenarios descargados, ya que se consideró que los escenarios descargados debían permanecer disponibles para futuras ejecuciones de la aplicación. 6 a iteración : consistió en implementar diferentes modos de juego que se acababan de denir en la reunión, para dotar mayor variedad al juego y lograr modos de juego con mayor diversión. Fue entonces cuando se implementaron los lugares de interés, direcciones y negocios reales que serían utilizados como objetivo a alcanzar en la partida, en lugar de las banderas, y también se implementó la funcionalidad de poder salir del vehículo y avanzar a pie. 7 a iteración : consistió en la implementación de una versión simplicada del sistema VESPA, añadiendo además todo lo necesario al juego para permitir su uso, como el radar en el que se mostrarían los eventos. Al nal de esta 45 iteración se mostró el trabajo realizado hasta el momento al profesor Thierry Delot (del proyecto VESPA), realizando una presentación en inglés en la que se anotaron diversas posibles mejoras, que serían implementadas en la siguiente iteración. 8 a iteración : se inició tras una reunión en la que se había realizado una prueba con los tutores del juego y se denieron multitud de ajustes y cambios de mayor calado que debían realizarse, además de nuevas características consideradas de interés. Se dedicó toda la iteración a realizar estos cambios. Fue aquí cuando se añadieron características como la cámara de muerte (permite a los jugadores muertos ver la visión del resto de jugadores para que la espera no sea aburrida) o el menú de pausa. 9 a iteración : se desarrolló la implementación completa del sistema VESPA, sustituyendo a la versión simplicada que se había estado usando previamente. Esta iteración fue muy costosa, ya que fue necesaria la lectura de diversos artículos de VESPA para la comprensión del sistema, y en la implementación se contaba con el código fuente de una versión no nal del simulador desarrollado para VESPA, el cuál contaba con varios errores por lo que fue necesario revisar detalladamente todo el código antes de poder usar las funciones que contenía. 10 a iteración : En este momento, con el sistema VESPA ya implementado, se decidió avanzar en la explotación del juego como método de evaluación de dicho sistema, comenzando la realización del artículo nalmente presentado en IMMoA'13 2 . Para ello, se vio necesaria una última iteración en la que se incluyera un nuevo modo de juego consistente en realizar aparcamientos, para facilitar la toma de muestras de tiempos de aparcamiento, análisis en el cuál se iba a centrar dicho artículo. También fue en este momento cuando se implementó el sistema de atascos, aunque no se llegó a usar para el artículo. Como se puede comprobar a continuación, se han cumplido todos los objetivos marcados inicialmente en la propuesta del Proyecto Fin de Carrera. Se ha desarrollado un videojuego de coches, que cuenta con vehículos controlados por el ordenador mediante la inteligencia articial elaborada, y con otros vehículos controlados por jugadores humanos, los cuales se unen a la partida a través de la red. Los escenarios utilizados para las partidas están creados con datos reales obtenidos del sistema cartográco OpenStreetMap. 2 http://www.dbis.rwth-aachen.de/IMMoA2013/ 46 Estos escenarios pueden ser añadidos al juego de forma sencilla desde el sistema de menús, indicando una localización a través de unas palabras clave (la dirección) y seleccionando el tamaño del área a descargar. Se ha denido una interfaz que permite utilizar en el juego sistemas de gestión de información, siendo implementado el sistema VESPA. Además, conjuntamente a lo realizado en este proyecto, se ha presentado un artículo (ver anexo E) al workshop IMMoA'13 , el cual ha sido realizado en conjunción con los directores del proyecto Sergio Ilarri y Eduardo Mena. 4.2. Línea temporal de la realización del proyecto Como ya se ha comentado anteriormente, el desarrollo del proyecto se ha realizado siguiendo una metodología de desarrollo basado en iteraciones. En esta sección se analizará el tiempo dedicado a cada iteración (tabla 4.2 y gura 4.2) así como la visión global dividiendo el tiempo en reuniones, investigación/análisis/diseño, implementación/pruebas y memoria (tabla 4.1 y gura 4.1). Hay que tener en cuenta que cada iteración consiste no solo de implementación sino también de la investigación, el análisis, el diseño y las pruebas realizadas. Por ese motivo la duración mostrada en la tabla 4.2 se incluye en los apartados investigación/análisis/diseño e implementación/pruebas de la tabla 4.1. También se muestra en la gura 4.3 el cronograma del desarrollo de las diferentes iteraciones. Como se puede observar, la extensión temporal de las diferentes iteraciones dieren con el valor mostrado en la columna Duración. Esto es así debido a la superposición de la realización del proyecto con diversas actividades laborales y también con la realización del artículo presentado en el workshop IMMoA'13 . Tarea Horas Reuniones 27 Investigación/Análisis/Diseño 136 Implementación/Pruebas 497 Medidas de tiempos (Explotación) 51 Memoria 172 Total 883 Tabla 4.1: Separación de horas por tipo de trabajo 47 Iteración Descripción Horas 1 Rally-X, OSM, inteligencia basica 59 2 Red 105 3 Multi-hilo, terrenos, mejora visual 72 4 Inteligencia avanzada 73 5 Menús, gestión escenarios 24 6 Modos de juego 73 7 VESPA simple 21 8 Menú de pausa, cámara de muerte y múltiples correcciones 79 9 VESPA completo 51 10 Mejoras para explotación 76 Total 633 Tabla 4.2: Separación de horas por iteración Figura 4.1: Porcentaje de horas de cada tipo de tarea 48 Figura 4.2: Porcentaje de tareas de cada iteración Figura 4.3: Cronograma del desarrollo de las diferentes iteraciones. Se han marcado en naranja los periodos de nula dedicación. 49 4.3. Trabajo futuro A continuación se proponen algunas posibles mejoras futuras, que se pueden dividir en varias temáticas: red, rendimiento, VESPA, IA y otros. Sobre aspectos de red Usar la Codicación Human como método de comprimir los paquetes de red, al igual que se hace en el juego Quake3 y el motor Source [13]. Cambiar el uso del TCP asíncrono usado para el envío de datos fuera de orden por el protocolo UDP con características de reliability implementadas. Este cambio es muy deseable ya que durante la redacción de esta memoria, revisando artículos de las fuentes, se descubrió un problema de usar los protocolos TCP y UDP simultaneamente que había pasado desapercibido. Todos los artículos relacionados con los aspectos de la comunicación en red recomendaban encarecidamente usar el protocolo UDP (por los motivos comentados en el Capítulo 2.8.1) y además mencionaban que mezclar el uso de TCP y UDP podía causar problemas de sincronización [9]. Después de haber leído esos artículos se desarrolló el envío de paquetes de red durante el game loop mediante el protocolo UDP y en la inicialización y nalización (ver Anexo B.5), en las que era la abilidad y no la velocidad lo primordial, mediante el protocolo TCP. Tiempo después, durante la optimización del código de red para reducir la cantidad de datos a enviar, sin recordar las advertencias de los artículos acerca de mezclar ambos protocolos, se ideó que ciertos datos que se enviaban solo cada mucho tiempo se enviasen por TCP para lograr así una ligera mejora en el tamaño de los paquetes enviados en cada ciclo. Los elementos que se decidió enviar por TCP son: las puntuaciones, la explicación de la ronda y los mensajes durante la partida (a veces referidos en este documento como mensajes GUI ). Durante la revisión de los artículos de la bibliografía realizada durante la preparación de este documento se recordó la advertencia del peligro del uso de ambos protocolos simultáneamente, e investigando más sobre el asunto se descubrió un artículo [19] en el que se explicaba que al estar ambos protocolos implementados sobre la capa IP, el uso de TCP tiende a inducir pérdida de paquetes en UDP. Es por esta razón que se debe cambiar de nuevo el envío de esos tres elementos que actualmente se realiza mediante TCP para volverlo a realizar en los paquetes Snapshot UDP o seguir con el diseño actual pero cambiando el uso de TCP por UDP e incorporar funcionalidades que garanticen la abilidad de los envíos. 50 Sobre aspectos del rendimiento Implementar un método que posibilite calcular el rendimiento del ordenador, para por ejemplo decidir de forma autónoma los parámetros más apropiados para la partida o el uso o no de las pantallas estáticas mencionadas en el punto anterior. Una forma de realizar esta funcionalidad podría ser ejecutar un proceso pesado y medir el tiempo utilizado. Disponer de diferentes resoluciones grácas, predenidas de antemano y seleccionables por el usuario. Sobre VESPA Realizar el cálculo de la Encounter Probability (EP) mediante el uso de mapas digitales en lugar de mapas geográcos. Usar la implementación real de VESPA como implementación de los interfaces, en lugar de hacer uso de la interfaz desarrollada para el juego. Hacer una vista general del juego donde se vea todo el área de juego en miniatura de forma que se pueda observar el comportamiento de VESPA (cómo se envían los eventos, quien los reenvía, etc.). Esta vista general se visualizaría desde un cliente especial que se conectase al servidor. Una funcionalidad adicional podría ser que se pudiera grabar la secuencia para posteriormente poder revisionarlo como si de un vídeo se tratara. Realizar una metodología para automatizar la recogida y procesado a gran escala de los cheros de estadísticas de explotación, así como realizar una evaluación en otros escenarios (con otros tipos de eventos, etc.). Esta extensión podría ser objeto de un Proyecto Fin de Carrera que continuara con el trabajo en este sentido. Sobre la IA Dividir el escenario en regiones para mejorar el rendimiento del algoritmo de detección de colisiones (para que compruebe las posibles colisiones solo con los elementos del terreno de tu región) y del algoritmo que averigua cuál es tu nodo más cercano (usado por la IA). Hacer que los vehículos del tráco respeten los sentidos de circulación en los caminos de doble sentido. Para lograr este objetivo, el algoritmo de path- nding debe poder diferenciar los sentidos de las calles (ya está así hecho) y se debe idear algún método para que el vehículo circule siempre próximo 51 al borde derecho del camino. Un problema que se encontraría sería que al reducirse a la mitad el espacio por el que circulan, podrían surgir problemas de maniobrabilidad de la inteligencia de los vehículos. Otra posibilidad sería utilizar un comportamiento similar al Flow eld following descrito en [17], para asegurar que en cada mitad del camino la fuerza que guiará a los vehículos sea en distinto sentido. Otros aspectos Actualmente cada tipo de terreno tiene asociadas unas propiedades (infranqueable, ralentizar, causar daño, etc.). Sería deseable poder controlar las propiedades que tendrá cada terreno según un chero de texto de conguración. Mostrar textos con colores y formato, en lugar de texto plano, en los textos durante el juego. Por ejemplo para mostrar el color de un equipo en los mensajes GUI o en la explicación de la ronda. Para lograr esta función se podría usar la clase AttributedText . Actualmente, las unidades de medida espacio-tiempo en torno a las cuales está diseñado el juego son los pixeles, los ciclos de juego y en menor medida los segundos. Se han utilizado éstas por motivos de sencillez pero sería conveniente cambiarlo de modo que se usen únicamente las respectivas unidades del S.I (metros y segundos). De esta forma garantizaríamos que la velocidad de los vehículos sea la misma aunque la velocidad del juego ( FPS ) disminuya. Usar SandMark 3 para ofuscar el código fuente del juego y así dicultar que se puedan hacer trampas en el juego. Hacer que la música de la partida cambie dinámicamente según la situación actual. Por ejemplo una música con un ritmo más rápido en situaciones de peligro. En [4] se muestra un método de crear música adaptativa mediante el uso de músicas MIDI . Sería recomendable que existiese una interfaz web con un diseño similar a los menús del juego desde la que se pudiesen modicar remotamente los cheros cong y paramCong.txt del servidor dedicado. 3 http://sandmark.cs.arizona.edu/ 52 4.4. Valoración personal El trabajo realizado ha sido muy satisfactorio, ya que me ha permitido cumplir el deseo de elaborar enteramente un videojuego, y además me ha aportado muchos conocimientos íntimamente ligados a dicho ámbito, así como muchos otros que seguro me son de gran utilidad en el ejercicio de mi carrera profesional. Durante la elaboración de este Proyecto Fin de Carrera me encontré con diversas dicultades que me supusieron un empleo de tiempo mayor de lo esperado. Las más importantes fueron: (1) la comprobación de que la implementación de VESPA desarrollada funcionaba de forma correcta, (2) la adaptación del cálculo de la Encounter Probability (EP) de VESPA a partir del simulador, poco documentado, enteramente en francés, y con varios fallos (que costó encontrar) ya que no se trataba de la versión nal, y la más importante, (3) el empleo de mucho tiempo de análisis, diseño e implementación de aspectos y características que en siguientes iteraciones se terminaron descartando, como por ejemplo buscar la forma de que el sonido del motor del coche fuera dinámico (con cambios de las marchas) o tratar el problema de los edicios que invadían la calzada y que dicultaban los algoritmos de la IA ). A estas dicultades habría que añadir la excesiva dilatación en el tiempo de la realización del proyecto, y su amplitud, que en ocasiones hacía difícil mantener la visión del conjunto, a pesar de la documentación desarrollada. Debido a estas dicultades y a la cantidad de errores iniciales a causa de la poca documentación existente acerca de algunos temas, en los que fui aprendiendo a base de errores, el proyecto se dilató excesivamente en el tiempo y hubo algunos momentos en los que me planteé si la elección del proyecto había sido acertada, pero la motivación que me suponía realizar un videojuego y el apoyo de mis tutores me permitió sobrellevar esos momentos de desánimo. A pesar de esto, considero muy útil toda mi experiencia en la realización del proyecto, tanto por lo aprendido como por lo trabajado, y me ha supuesto una gran satisfacción personal ver la evolución del desarrollo del videojuego hasta lo que es ahora. 53 Anexo A Análisis Para la elaboración de este Proyecto Fin de Carrera se ha seguido una metodología de desarrollo basada en diferentes iteraciones del producto, de forma que en cada reunión se establecían los objetivos del siguiente prototipo. Debido a que se realizaron muchas iteraciones con relativamente pocos cambios entre ellas, en este anexo se muestran únicamente los diferentes aspectos del análisis correspondiente a la última iteración (salvo que se indique lo contrario). A.1. Requisitos A continuación se muestran los requisitos de la última iteración del juego. 1. Generales R1.1. La aplicación se tratará de un juego de coches R1.2. Podrán jugar varios usuarios en una misma partida a través de la red R1.3. Se elaborarán diversos modos de juego (pruebas de carácter competitivo) R1.4. Se elaborará una IA para el control de los vehículos no humanos 2. Jugabilidad R2.1. Se tomará como base para el juego el clásico videojuego Rally-X (Namco 1980) 1 R2.1.1. Existirán vehículos enemigos que nos persigan 1 http://en.wikipedia.org/wiki/Rally-X 61 R2.1.2. Existirán banderas que haya que recolectar R2.1.3. Los jugadores podrán hacer uso de bombas de humo que despistarán a los enemigos R2.1.4. Los jugadores tendrán una cantidad de combustible limitada que se recargará conforme se avance de nivel R2.1.5. Los jugadores tendrán una cantidad de salud limitada que se recargará conforme se avance de nivel R2.1.6. El juego dispondrá de diversos niveles en los que se irá avanzando hasta ser eliminado R2.2. Se añadirán elementos para demostrar las ventajas del uso de VANETs R2.2.1. Existirán otros vehículos no humanos cumpliendo la función de tráco R2.2.2. Existirán plazas de aparcamiento en las cuales podrán aparcar tanto los vehículos del tráco como los jugadores R2.2.3. Existirán vehículos de servicios de emergencia R2.3. El jugador podrá abandonar el vehículo y avanzar andando R2.4. El jugador, mientras esté muerto, podrá mover la cámara libremente por el escenario o ver lo que hacen los otros jugadores, con el objetivo de amenizar la espera hasta que sea revivido 3. Escenarios R3.1. Se podrá jugar en diferentes escenarios reales R3.2. Los escenarios se obtendrán mediante un servicio de mapas online R3.2.1. Los escenarios se obtendrán a través del servicio OpenStreetMap R3.3. Se podrán previsualizar los escenarios descargados R3.4. Se almacenarán y consultarán localmente los mapas y las imágenes de previsualización de los mismos 62 4. Interfaz R4.1. Todos los textos del juego se elaborarán en inglés R4.1. La navegación por los menús de la aplicación se realizará mediante una interfaz gráca R4.2. El usuario podrá crear una partida nueva R4.3. El usuario podrá unirse a una partida en red R4.4. El usuario podrá gestionar los mapas almacenados: añadir, previsualizar y eliminar R4.5. El juego dispondrá de música tanto durante la navegación por los menús como durante la partida R4.6. El usuario podrá subir y bajar el volumen de música, así como también desconectarla R4.7. Se creará una pantalla en la que se indiquen datos sobre el autor, los directores del proyecto y se agradezcan los usos de librerías y melodías utilizadas. R4.8. Existirán varias conguraciones de dicultad cerradas: alta, media y baja R4.9. Se noticará a los demás jugadores cuando un jugador se haya desconectado R4.10. Se mostrará una barra de progreso durante el proceso de carga de la partida 5. VANETs R5.1. Se permitirá la integración en el juego de un sistema de gestión de datos ( VANET ) R5.2. En concreto, se integrará el sistema VESPA R5.3. Se permitirán simular situaciones reales en las que se puedan evaluar el efecto que podría tener la utilización de un sistema de gestión de datos R5.4. Se denirán los interfaces Java básicos (o clases abstractas) necesarias para desde el videojuego poder interaccionar con VESPA 63 R5.5. Se implementará una instanciación de dichos interfaces para poder probar VESPA en el juego 6. Entorno R6.1. La aplicación se realizará sobre Java R6.2. La aplicación podrá ejecutarse como aplicación de escritorio y también como Applet R6.3. La aplicación debe funcionar en Windows XP, Linux y Mac OS X 7. Técnicas R7.1. Se usará el protocolo UDP para la comunicación habitual entre el cliente y el servidor R7.2. El cliente y el servidor estarán acoplados en una sola entidad, de forma que el jugador solo tenga que abrir una instancia para poder jugar R7.3. La aplicación será multi-hilo 8. Otros R8.1. El comportamiento de los vehículos no humanos, la IA del juego, deberá estar completamente aislado de todo lo demas, de forma que se pueda cambiar el comportamiento incluso sin reprogramar nada o muy poco (depende del cambio) R8.2. El usuario se podrá unir a la partida sobre la marcha, durante el trascurso de una partida A.2. Casos de uso En esta sección se mostrarán los diagramas de casos de usos analizados. El análisis se ha dividido entre, por un lado, la navegación por los menús hasta iniciar la partida (gura A.1) y por otro lado la partida en sí. Además, el análisis de la partida se ha separado en diferentes diagramas: uno general (gura A.2), en el que se han simplicado todas las acciones del jugador y otros en los que se detallan dichas acciones según el modo de juego escogido. 64 Modificar configuración avanzada VESPA Navegación menús Modificar configuración VESPA Modificar configuración de red (creación) Eliminar mapa Visualizar mapa Añadir mapa Gestionar mapas Modificar reglas Configurar creación partida Crear una partida nueva Modificar configuración de red (unión) Configurar unión a partida Unirse a una partida existente Modificar directorio de juego Modificar volumen música Modificar volumen efectos Modificar controles Modificar opciones Ver créditos Usuario <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Include>> <<Extend>> <<Include>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> Figura A.1: Casos de uso: navegación menús 65 Cuando se supera el tiempo límite por ronda se finaliza la partida Reloj Juego (simplificado) Usuario ajeno Siguiente ronda Lograr objetivo Finalizar partida Abandonar Ver controles Modificar volumen Sacar menú Realizar acción Unirse a partida Iniciar partida Usuario anfitrión <<Include>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> <<Extend>> Figura A.2: Casos de uso: partida Reincorporarse Capturar bandera Realizar acción Usuario Echar humo Aparcar Lograr objetivo Mover <<Extend>> <<Extend>> Figura A.3: Casos de uso: detalle del modo de juego capture the ags 66 Reincorporarse Usuario Echar humo Aparcar Lograr objetivo Mover Dañar Realizar acción <<Extend>> <<Extend>> Figura A.4: Casos de uso: detalle del modo de juego capture the red cars Reincorporarse Entrar al vehículo Salir del vehículo Usuario Echar humo Aparcar Lograr objetivo Mover Realizar acción <<Include>> <<Extend>> <<Extend>> <<Extend>> Figura A.5: Casos de uso: detalle del modo de juego solve the task y task endurance survival 67 Reincorporarse Entrar al vehículo Salir del vehículo Echar humo Aparcar Lograr objetivo Mover Usuario Realizar acción <<Include>> <<Extend>> <<Extend>> Figura A.6: Casos de uso: detalle del modo de juego parking special mode 68 Menús Nombre: Ver créditos Descripción: El usuario visualiza la pantalla que contiene información sobre el juego, el autor y sobre VESPA Precondiciones: El usuario se encuentra en la pantalla inicial del menú Postcondiciones: El usuario se encuentra en la pantalla inicial del menú Flujo normal: 1. El usuario demanda la carga de la pantalla créditos 2. El sistema muestra la pantalla créditos al usuario 3. El usuario demanda volver a la pantalla anterior Nombre: Modicar opciones Descripción: El usuario visualiza la pantalla que permite cambiar la con- guración del volumen, controles y directorio de juego. Precondiciones: El usuario se encuentra en la pantalla inicial del menú Postcondiciones: El usuario se encuentra en la pantalla inicial del menú Flujo normal: 1. El usuario demanda la carga de la pantalla créditos 2. El sistema muestra la pantalla opciones al usuario 3. El usuario realiza las modicaciones deseadas a la con- guración 4. El usuario demanda volver a la pantalla anterior guardando los cambios realizados Flujo alternativo: 3a. El usuario desea modicar el volumen de la música 1. Caso de uso Modicar volumen música 3b. El usuario desea modicar el volumen de los efectos 1. Caso de uso Modicar volumen efectos 3c. El usuario desea modicar el directorio de juego 1. Caso de uso Modicar volumen efectos 3d. El usuario desea modicar los controles 1. Caso de uso Modicar controles 4a. El usuario no desea guardar los cambios realizados 1. El usuario demanda volver a la pantalla anterior desechando los cambios realizados Nombre: Modicar controles Descripción: El usuario visualiza la pantalla que permite visualizar y modicar los controles del juego. Precondiciones: El usuario se encuentra en la pantalla opciones del menú  continúa en la siguiente página  69  continúa de la página anterior  Precondiciones: El usuario se encuentra en la pantalla iniciar del menú Postcondiciones: El usuario se encuentra en la pantalla iniciar del menú Flujo normal: 1. El usuario demanda la carga de la pantalla de gestión de mapas 2. El sistema muestra dicha pantalla al usuario 3. El usuario modica los parámetros deseados 4. El usuario demanda volver a la pantalla anterior guardando los cambios realizados Flujo alternativo: 3a. El usuario desea descargar un nuevo mapa 1. Caso de uso Añadir mapa 3b. El usuario desea visualizar un mapa descargado 1. Caso de uso Visualizar mapa 3c. El usuario desea eliminar un mapa descargado 1. Caso de uso Eliminar mapa Nombre: Añadir mapa Descripción: El usuario añade un nuevo mapa al juego. Precondiciones: El usuario se encuentra en la pantalla de gestión de mapas Postcondiciones: El usuario se encuentra en la pantalla de gestión de mapas Flujo normal: 1. El usuario introduce las palabras clave de la dirección que desea buscar, un alias y el tamaño deseado y demanda al sistema la realización de la búsqueda 2. El sistema muestra al usuario una lista con todas las coincidencias de la búsqueda 3. El usuario elige el mapa deseado de dicha lista. 4. El usuario visualiza y/o descarga el mapa Flujo alternativo: 2a. No existe ninguna coincidencia 1. Se le informa al usuario de ello. 4a. Se desea visualizar el mapa 1. El usuario demanda visualizar el mapa a descargar 2. El sistema muestra una vista previa de dicho mapa al usuario 4b. Se desea descargar el mapa 1. El usuario demanda la adición del mapa al juego 2a. El sistema descarga dicho mapa y lo añade a la lista de mapas disponibles. 2b. El alias ya existe 1. Se informa al jugador resaltando el campo  continúa en la siguiente página  76  continúa de la página anterior  2c. La dirección elegida ya existe con ese mismo tamaño 1. Se le informa al usuario mediante una ventana emergente de error 1a, 3a, 4c. El usuario no desea realizar cambios 1. El usuario demanda volver a la pantalla anterior Nombre: Visualizar mapa Descripción: El usuario visualiza un mapa ya descargado Precondiciones: El usuario se encuentra en la pantalla de gestión de mapas Postcondiciones: El usuario se encuentra en la pantalla de gestión de mapas Flujo normal: 1. El usuario selecciona de la lista el mapa que desea visualizar 2. El sistema muestra una vista previa de dicho mapa al usuario Nombre: Eliminar mapa Descripción: El usuario elimina un mapa ya descargado Precondiciones: El usuario se encuentra en la pantalla de gestión de mapas Postcondiciones: El usuario se encuentra en la pantalla de gestión de mapas Flujo normal: 1. El usuario selecciona de la lista el mapa que desea eliminar 2. El sistema muestra una ventana emergente pidiendo la conrmación del usuario 3. El usuario aprueba la eliminación 4. El sistema elimina dicho mapa de los cheros de datos del juego y de la tabla. Flujo alternativo: 3a. El usuario cancela la eliminación 1. El usuario demanda la cancelación de la operación Partida (simplicado) Nombre: Iniciar partida Descripción: Se inicia una nueva partida y el jugador comienza a jugar Actores: Usuario antrión Precondiciones: Menú en pantalla iniciar con todos los parámetros ya congurados de forma correcta  continúa en la siguiente página  77  continúa de la página anterior  Postcondiciones: El sistema cierra el sistema de menús e incorpora al jugador a la partida que se crea. Flujo normal: 1. Caso de uso Crear una partida nueva 2. Caso de uso Siguiente ronda Nombre: Unirse a partida Descripción: El jugador se une a una partida en red ya existente Actores: Usuario ajeno Precondiciones: Menú en pantalla unirse con todos los parámetros ya congurados de forma correcta Postcondiciones: El sistema cierra el sistema de menús e incorpora al jugador a la partida deseada. Flujo normal: 1. Caso de uso Unirse a una partida existente Nombre: Sacar menú Descripción: Muestra en pantalla el menú de pausa Actores: Usuario antrión, usuario ajeno Precondiciones: El usuario está jugando una partida Flujo normal: 1. El usuario presiona la tecla encargada de hacer aparecer el menú 2. El sistema muestra dicho menú. 3. El usuario realiza las operaciones deseadas 4. El usuario vuelve a la partida pulsando de nuevo la tecla establecida o mediante la pulsación de la opción del menú. Flujo alternativo: 3a. La operación deseada es modicar el volumen 1. Caso de uso Modicar volumen 3b. La operación deseada es ver los controles 1. Caso de uso Ver controles 3c. La operación deseada es abandonar la partida 1. Caso de uso Abandonar Nombre: Modicar volumen Descripción: Modica el volumen de los efectos y/o de la música Actores: Usuario antrión, usuario ajeno Precondiciones: El usuario está con el menú de pausa desplegado Postcondiciones: El usuario está con el menú de pausa desplegado  continúa en la siguiente página  78  continúa de la página anterior  Flujo normal: 1. El usuario elige la opción options del menú 2. El sistema le muestra la pantalla de dicha opción 3. El usuario sube o baja los niveles del volumen de los efectos y de la música mediante los botones habilitados 4. El usuario acepta los cambios 5. El sistema muestra la pantalla inicial del menú Nombre: Ver controles Descripción: Muestra al usuario las teclas asociadas con los diferentes controles Actores: Usuario antrión, usuario ajeno Precondiciones: El usuario está con el menú de pausa desplegado Postcondiciones: El usuario está con el menú de pausa desplegado Flujo normal: 1. El usuario elige la opción show controls del menú 2. El sistema le muestra la pantalla de dicha opción 4. El usuario acepta volver a la pantalla anterior 5. El sistema muestra la pantalla inicial del menú Nombre: Abandonar Descripción: El usuario abandona la partida actual Actores: Usuario antrión, usuario ajeno Precondiciones: El usuario está con el menú de pausa desplegado Postcondiciones: El usuario está con el menú de pausa desplegado Flujo normal: 1. El usuario elige la opción end game del menú 2. El sistema le muestra un mensaje de conrmación 3. El usuario acepta abandonar la partida 4. El sistema abandona la partida y se carga de nuevo el sistema de menús mostrándose la pantalla de resumen de la partida Flujo alternativo: 3a. El usuario no abandona la partida 1. El usuario elige la opción de continuar jugando 5a. El usuario es el antrión de la partida 1. Caso de uso Finalizar partida Nombre: Finalizar partida Descripción: El usuario naliza la partida actual  continúa en la siguiente página  79  continúa de la página anterior  Actores: Usuario antrión, reloj Precondiciones: El usuario antrión acaba de abandonar la partida Postcondiciones: El usuario naliza la partida para todos los jugadores Flujo normal: 1. El sistema cierra el servidor de la partida, de forma que todos los jugadores presentes vuelven a cargar el sistema de menús y se les muestra la pantalla de resumen de la partida Nombre: Siguiente ronda Descripción: Se avanza a la siguiente ronda de la partida Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso Postcondiciones: Se aumenta el nivel de ronda de la partida Flujo normal: 1. El sistema comprueba cuántas rondas se han superado Flujo alternativo: 2a. número rondas superadas ≥ número límite 1. Caso de uso Finalizar partida Nombre: Lograr objetivo Descripción: Un usuario ha logrado un objetivo del modo de juego Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso Postcondiciones: Se elimina un objetivo de la lista de objetivos Flujo normal: 1. Se elimina el objetivo de la lista de objetivos 2. El sistema comprueba cuantos objetivos quedan Flujo alternativo: 2a. No quedan objetivos 1. Caso de uso Siguiente ronda Nombre: Realizar acción Descripción: El usuario, mediante un evento de teclado, modica el estado del actor que le representa en el mundo de juego Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso Postcondiciones: La acción seleccionada se ve reejada en el mundo de juego (salvo pérdida de paquetes de red) Flujo normal: 1. El usuario pulsa la tecla asignada a la acción que desea realizar  continúa en la siguiente página  80  continúa de la página anterior  2. El sistema reeja dicha acción en el mundo de juego. Flujo alternativo: 3a. Mediante dicha acción se ha logrado completar un objetivo 1. Caso de uso Lograr objetivo Partida (detalle de Realizar acción) Nombre: Echar humo Descripción: El usuario, mediante un evento de teclado, crea una nube de humo situada tras el vehículo que le representa. Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. Cantidad de nubes de humo restantes mayor que cero. Postcondiciones: El vehículo que representa al jugador crea una nube de humo tras él. Flujo normal: 1. El usuario pulsa la tecla asignada a la acción de echar humo. 2. El sistema reeja dicha acción en el mundo de juego. Nombre: Aparcar Descripción: El vehículo representado por el usuario estaciona en una plaza de aparcamiento. Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. Actor del usuario situado sobre una plaza de aparcamiento libre. Postcondiciones: El usuario estaciona en la plaza de aparcamiento. La plaza de aparcamiento cambia a estado ocupada. Flujo normal: 1. El usuario pulsa la tecla asignada a la acción de aparcar 2. El vehículo del jugador se queda inmóvil 3. La plaza de aparcamiento pasa a estar ocupada Flujo alternativo: 4a. Dicha plaza es uno de los objetivos de la ronda 1. Caso de uso Lograr objetivo 5a. Modo de juego solve the task, task endurance survival o parking special mode 1. Caso de uso Salir del vehículo Nombre: Reincorporarse  continúa en la siguiente página  81  continúa de la página anterior  Descripción: El vehículo representado por el usuario abandona la plaza de aparcamiento en la que se encuentra, reincorporándose a la circulación Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. Actor del usuario estacionado en una plaza de aparcamiento. Postcondiciones: El usuario abandona la plaza de aparcamiento en la que se encontraba. La plaza de aparcamiento cambia a estado libre. Flujo normal: 1. El usuario pulsa la tecla asignada a la acción de aparcar 2. El vehículo del jugador recupera la movilidad 3. La plaza de aparcamiento en la que el jugador estaba aparcado pasa a estar libre Nombre: Salir del vehículo Descripción: El actor que representa al usuario abandona el vehículo y prosigue a pie. Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. Actor del usuario estacionado en una plaza de aparcamiento. Modo de juego solve the task, task endurance survival o parking special mode. Postcondiciones: El vehículo del usuario continúa en la misma posición estacionado sobre la plaza de aparcamiento. El jugador pasa a controlar un hombre a pie, con distintas características de velocidad, giro, salud, etc. Flujo normal: 1. El usuario pulsa la tecla asignada a la acción de aparcar 2. El usuario pasa a controlar al conductor del vehículo, que se mueve a pie. Nombre: Entrar al vehículo Descripción: El actor que representa al usuario entra al vehículo Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. Actor del usuario próximo a su vehículo estacionado. Modo de juego solve the task, task endurance survival o parking special mode.  continúa en la siguiente página  82  continúa de la página anterior  Postcondiciones: El vehículo del usuario continúa en la misma posición estacionado sobre la plaza de aparcamiento. El jugador pasa a controlar un hombre a pie, con distintas características de velocidad, giro, salud, etc. Flujo normal: 1. El usuario pulsa la tecla asignada a la acción de aparcar 2. El usuario pasa a controlar al vehículo 3. Caso de uso Reincorporarse Nombre: Mover Descripción: El usuario realiza un desplazamiento por el mundo de juego, dado por su actual velocidad y ángulo Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. El usuario no está estacionado en una plaza de aparcamiento. Postcondiciones: El actor que representa al usuario se habrá desplazado (salvo que haya colisionado con los límites de la calzada) Flujo normal: 1. El usuario pulsa una de las teclas asignadas al control del vehículo 2. El actor que representa al usuario se desplaza en el mundo de juego Flujo alternativo: 2a. El resultado del desplazamiento sitúa al actor fuera de los límites de la calzada transitable 1. El actor se desplaza únicamente la cantidad suciente para no salirse de los límites 3a. El resultado del desplazamiento es una colisión contra otro vehículo al que persigue 1. Caso de uso Dañar 3b. El resultado del desplazamiento es una colisión contra otro vehículo al que no persigue y la vida del usuario no es innita 1. El actor sufre una cantidad establecida de daños. 3c. El resultado del desplazamiento es una colisión con una bandera 1. Caso de uso Capturar bandera 3d. El resultado del desplazamiento es coincide con el radio de un lugar objetivo 1. Caso de uso Lograr objetivo 83 Nombre: Capturar bandera Descripción: El usuario captura una bandera en el mundo de juego desplazándose sobre ella. Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso Postcondiciones: La bandera desaparece y se suma al usuario la puntuación correspondiente Flujo normal: 1. El actor que representa al usuario colisiona con la bandera 2. El sistema elimina dicha bandera del mundo de juego 3. El sistema incrementa la puntuación del usuario en la cantidad establecida. Nombre: Dañar Descripción: El usuario causa daño a otro vehículo colisionando con él Actores: Usuario antrión, usuario ajeno Precondiciones: Existe una partida en curso. Modo de juego capture the red cars Postcondiciones: El vehículo contra el que colisiona el usuario recibe una cantidad de daño establecida. Flujo normal: 1. El actor que representa al usuario colisiona contra otro vehículo 2. El sistema disminuye la cantidad de vida de dicho vehículo Flujo alternativo: 2a. La vida del otro vehículo es menor que la cantidad a sustraer 1. El sistema elimina al otro vehículo del mundo de juego 2. El sistema incrementa la puntuación del usuario 3a. El otro vehículo es un objetivo de la ronda 1. Caso de uso Lograr objetivo A.3. Diagrama de navegación En esta sección se muestran el diagrama de pantallas elaborado durante la primera iteración del juego (Figura A.7) y el elaborado durante la última iteración (Figura A.8). Como se puede apreciar en dichas guras, se realizaron diversos cambios ya que cada nueva iteración desarrollada a veces requería de nuevas funcionalidades del 84 menú. Los principales cambios desde la versión inicial a la nal fueron: Eliminación de las salas de espera, ya que al principio el juego se ideó e implementó de forma que los jugadores solo se podían unir al comienzo de la partida, y éstas salas eran necesarias para que el jugador antrión controlase la cantidad de jugadores esperando y el resto de jugadores tuviesen una pantalla en la que esperar al comienzo del juego. En el momento en que se vio que esta forma de unión, basada en los juegos más clásicos (como las sagas Age of Empires o Empire Earth ) no era la óptima para un juego de estas características, se cambió por el método de unión sobre la marcha, utilizado en la gran mayoría de juegos actuales. Se incrementó el número de pantallas desde las cuales se podía derivar a una pantalla de error si fuera necesario. Se añadieron nuevas pantallas para los créditos y las opciones globales, cuyo contenido estaba incluido inicialmente en otras pantallas menos accesibles, y también una pantalla secreta, a la que solo se puede acceder con el conocimiento de una combinación de teclas especíca, para cambiar durante la implementación y las pruebas diversos valores que hasta el momento requerían de una recompilación de todo el código lo cual era muy farragoso. 85 Figura A.16: Prototipo de ventana de reglas del juego Figura A.17: Prototipo de ventana de gestión de mapas 92 Figura A.18: Prototipo de ventana vista previa mapa Figura A.19: Prototipo de ventana sala de espera (en creación) 93 Figura A.20: Prototipo de ventana conrmación creación Figura A.21: Prototipo de ventana cargando partida 94 Figura A.22: Prototipo de ventana resumen después de partida A.5. Modos de juego A lo largo de diferentes reuniones y conversaciones por correo electrónico se analizó que diferentes modos de juego debían desarrollarse. Las tablas que contienen las conclusiones de dichas reuniones se pueden observar en las guras A.23 y A.24. TIPO Jugadores Equipos Cuando se acaba Obje!vo Enemigos IA Compe!dores humanos Comportamiento enemigos Banderas Perseguir Enemigos Huir si Perseguir no - 1 1 no 2..n 2..n si 1 1 no 2..n 2..n si 1..n 1 2..n 2..n Capturar banderas o coches enemigos si no si Banderas Enemigos por !empo o por obje!vo * si si Huir Perseguir Seguir un plan finito Perseguir si * por agotarse el dinero Seguir un plan infinito Figura A.23: Modos de juego. Los objetivos marcados como asterisco (*) son tareas que pueden ser de los diferentes tipos desglosados en la gura A.24 Como se puede observar en la gura A.23, todos los modos de juego nalmente implementados corresponden a los de esta tabla a excepción del modo de juego 95 Tipo Donde Alias Explicacion en coche llegar con el coche hasta el objevo aparcar aparcar en una plaza libre cercana a pie aparcar y llegar a pie hasta el objevo en coche llegar con el coche hasta el objevo aparcar aparcar en una plaza libre cercana a pie aparcar y llegar a pie hasta el objevo ir a dirección negocio Figura A.24: Tipos de tarea de los modos de juego de realizar tareas de aparcamiento parking special mode, esto es así ya que ese modo de juego no estaba previsto inicialmente y se desarrolló durante la etapa nal del proyecto, con el objetivo de tener un modo de juego que facilitase la realización de los experimentos asociados a la explotación. Éste modo de juego es una variación del modo seguir un plan nito con la particularidad de que cada ronda se divide en dos subrondas de forma que en la primera de ellas la tarea es siempre de tipo llegada en coche y la segunda de tipo lograr aparcamiento. 96 Anexo B Diseño En este capítulo se mostrarán las diferentes capas y módulos que componen la arquitectura diseñada, junto con las clases más importantes de cada módulo. También se explicará el despliegue de la aplicación cuando se usan los servidores dedicados y el servidor de recogida de estadísticas. Por último, se nalizará explicando el llamado game loop (bucle de juego) y los hilos existentes en la ejecución. También es importante anotar la autoría externa del diseño visual y sonoro de los vehículos y otros elementos del juego, si bien en su mayor parte han tenido que ser modicados para ajustarlos a las necesidades del videojuego. B.1. Arquitectura de la aplicación La arquitectura de la aplicación permite obtener un diseño a alto nivel del sistema, identicando los módulos de los que consta y las relaciones entre dichos módulos. El diseño que se ha realizado no se ha basado en ningún modelo especíco existente, sino que se ha realizado un diseño especíco para el videojuego desarrollado. En la gura B.1 se muestran los distintos módulos de los que se compone la aplicación y sus relaciones. El papel realizado por cada uno de los módulos se expone a continuación. Menús : es el módulo que controla los menús del juego y todo lo necesario para su funcionamiento: obtención de dirección IP, carga de la conguración y los parámetros, etc. Gestor de escenarios : controla la gestión de los escenarios, desde lo relativo a su almacenamiento hasta su obtención a través de las APIs de OpenStreetMap. 97 <<component>> Servidor <<component>> Cliente <<component>> Actores <<component>> DMS <<component>> Interfaz con DMS <<component>> Gestor de conexiones <<component>> Gestor de rondas <<component>> Estadísticas <<component>> Servidor maestro <<component>> Servidor estadístico <<component>> Logger <<component>> Salida <<component>> Gestor de escenarios <<component>> Menús <<component>> Física <<component>> Inteligencia Artificial <<component>> Menú in-game <<component>> Terreno Figura B.1: Diagrama de componentes Cliente : el núcleo con la parte cliente del juego, que es la representación visual de la partida y las funciones necesarias para obtener a través de la red los datos del mundo de juego. Salida : contiene todo lo relacionado con el sonido( gestor de música mp3 y gestor de efectos de sonido, con sus correspondientes ltros) y con la gestión y representación de sprites . Menú in-game : es el módulo que controla el menú de pausa que se habilita durante la partida. Servidor : el núcleo con la parte servidor del juego. Contiene todo lo relativo a la partida a excepción de su representación. Gestor de rondas : gestiona las rondas y los objetivos pendientes y controla el modo de juego aplicado. Inteligencia articial : contiene las clases referidas al manejo autónomo de los vehículos y también lo referente a los algoritmos de path-nding . Terreno : es el módulo en el que se denen los diferentes tipos de entidades usadas para la representación de los escenarios. 98 Actores : contiene a todos los actores de la partida. Física : se encarga de la simulación física de la partida. Gestor de conexiones : es el módulo que contiene todos los elementos que intervienen en la transmisión de información a través de la red. DMS : contiene los interfaces del sistema DMS y la implementación de la estrategia utilizada (en este caso VESPA). Interfaz con DMS : contiene los interfaces que deben implementar los actores para ser accesibles desde el DMS. Logger : es el módulo que controla la presentación en la consola de diferentes trazas de ejecución. Estadísticas : contiene todo lo necesario para la obtención de estadísticas del juego y del DMS. Servidor maestro : permite el uso de un servidor dedicado para las partidas y contiene también el proceso que se usa para la comunicación remota con dicho servidor. Servidor estadístico : contiene todo lo relacionado con el servidor de recogida de estadísticas. B.2. Capas de la arquitectura Se pueden distinguir dos capas diferenciadas en la arquitectura: la capa del núcleo y la capa de los suplementos. Núcleo : Esta capa contiene todos los elementos necesarios para el funcionamiento del juego. Cualquier cambio dentro de esta capa alterará el funcionamiento del juego. Dentro de esta capa se controla tanto lo referente a la partida como a la navegación por los menús. Suplementos : Esta capa contiene los elementos que no son imprescindibles para el funcionamiento del juego y que pueden ser alterados, sustituidos o eliminados sin afectar al resto de módulos. Un ejemplo es el fácil reemplazamiento del módulo DMS (Data Management Strategy) que es explicado con detalle en el anexo D.1. En la gura B.2 se representa la clasicación de los distintos módulos del diagrama de componentes diferenciados según su capa (en color blanco los módulos de la capa núcleo y en gris los módulos de la capa suplementos). 99 <<component>> Servidor <<component>> Cliente <<component>> Actores <<component>> DMS <<component>> Interfaz con DMS <<component>> Gestor de conexiones <<component>> Gestor de rondas <<component>> Estadísticas <<component>> Servidor maestro <<component>> Servidor estadístico <<component>> Logger <<component>> Salida <<component>> Gestor de escenarios <<component>> Menús <<component>> Física <<component>> Inteligencia Artificial <<component>> Menú in-game <<component>> Terreno Capa Suplementos Capa Nucleo Figura B.2: Capas de la arquitectura B.3. Despliegue En esta sección se puede ver el despliegue de los diferentes componentes, desglosado en dos guras (gura B.3 y gura B.4) según si se usa o no un servidor dedicado. Es importante anotar que todos los componentes de la aplicación se distribuyen conjuntamente empaquetados en un chero JAR, por lo que estos diagramas muestran únicamente los componentes de los que se hace uso desde cada ubicación. En el caso de no usar un servidor dedicado (gura B.3), el jugador antrión crea la partida conectándose la parte cliente de la aplicación con la parte servidor (a través de la red, de igual forma que si la conexión se realizara entre diferentes computadores). El resto de jugadores se conectarán únicamente sus partes cliente de la aplicación con la parte servidor del jugador antrión. Cuando nalice la partida, las estadísticas recogidas durante la partida se almacenarán en cheros locales del computador del jugador antrión y también realizará una conexión con el servidor de recogida de estadísticas, para que en el caso de que éste responda, enviarle dichas estadísticas. 100 Computador Cliente (Juego) Jugador n Computador recogida estadís!cas Servidor Estadís!co Estadís!cas Guardar estadís!cas del juego Miembro del equipo de recogida de estadís!cas Computador Cliente (Juego) Jugador 2 ... ... Computador anfitrión Estadís!cas Servidor (Juego) Cliente (Juego) Guardar estadís!cas del juego Usuario interesado en estadís!cas Conectarse al servidor Conectarse al servidor Enviar estadís!cas Jugador 1 Conectarse al servidor Figura B.3: Pseudo diagrama de despliegue sin servidor dedicado 101 -cards : JPanel -bi : BufferedImage -rop : RescaleOp -imgFondoCalle : BufferedImage +altura : int = 960 -translateTimer : Timer -pane : Container <<Property>> -imgTiraBlanca : BufferedImage <<Property>> -imgFondoCoche : BufferedImage -tcanvas : Thread -PLAYBACK_FORMAT : AudioFormat = new AudioFormat(44100,16,1,true,false) -volumenEfectos : float -volumenMusica : float +parametros : Parametros +ventana : VentanaPPal +soundManagerEfectos : SoundManager -soundManagerMusica : MiPlayer +sonidoOver : Sound +sonidoClick : Sound +ipAddressValidator : IPAddressValidator +Contenedor(pan : Container, ventan : VentanaPPal, tipoLlamada : int, parametro : Parametros) +translate(translate : int) : void +borrar() : void -initSounds() : void -startMusic() : void +lanzarJuego() : void -lanzarServidor(carga : PantallaCarga, serverReady : Semaphore) : void +lanzarCliente(carga : PantallaCarga, serverReady : Semaphore) : void +setSoundVolume(volumen : float) : void +setMusicVolume(volumen : float) : void +pintarCargando() : PantallaCarga +calcularModoDeJuego(modoJuego1 : int, modoJuego2 : int, modoJuego3 : int) : byte +calcularModoDeJuegoInverso(modo : int) : int [] +getImgTiraBlanca() : BufferedImage +getImgFondoCoche() : BufferedImage Contenedor Figura B.10: Detalle de la clase Contenedor 108 -cards : JPanel #bi : BufferedImage #rop : RescaleOp #imgFondoCalle : BufferedImage #ventana : VentanaPPal +contenedor : Contenedor #mkl : MyKeyListener +PantallaAnimada(cards : JPanel, ventana : VentanaPPal, bi : BufferedImage, rop : RescaleOp, imgF... -initComponents() : void +crearImagenOpaca(imageSrc : URL) : BufferedImage +crearImagenTransparenteBI(imageSrc : URL) : BufferedImage +crearImagenTransparenteROP(opacity : float) : RescaleOp +pintarImagenOpaca(g : Graphics, img : BufferedImage, observer : ImageObserver) : void +pintarImagenTransparente(g2 : Graphics, img : BufferedImage, rp : RescaleOp, x : int, y : int) : void +cambiarPantalla(ventana : String) : void #sonidoOver() : void #sonidoClick() : void #labelMouseEntered(evt : MouseEvent, label : JLabel) : void #labelMouseExited(evt : MouseEvent, label : JLabel) : void #buttonMouseEntered(evt : MouseEvent, label : JLabel) : void #buttonMouseExited(evt : MouseEvent, label : JLabel) : void #buttonMousePressed(evt : MouseEvent, label : JLabel) : void #buttonMouseReleased(evt : MouseEvent, label : JLabel) : void #pintarCuadrado(panel : JPanel, g : Graphics) : void #pintarCuadradoOpaco(panel : JPanel, g : Graphics, c : Color) : void +isFocusable() : boolean #volverAtras() : void #iniciarKeyListener(contenedor : Container) : void #iniciarMouseMotionListener(contenedor : Container, mmml : MouseMotionListener) : void #guardarConfigEnFichero() : void #cargarConfigDeFichero() : boolean PantallaAnimada Figura B.11: Detalle de la clase PantallaAnimada 109 que contienen los valores de conguración almacenados en las pantallas y los valores descritos mediante el chero de texto ParamCong.txt respectivamente. La clase TrainedSkills es la que contiene las funciones y estructura necesarias para el cálculo de la pericia del jugador (ver 3.3), y la clase WrapperCarga es la utilizada para poder transmitir el estado actual de carga de la partida desde la clase Cliente a la barra de progreso de la pantalla de carga. B.4.3. Módulo gestor de escenarios El módulo gestor de escenarios contiene las clases que permiten el manejo y almacenamiento de los mapas. workers mapas util juego WorkerAddMap WorkerSearchMap WorkerViewMapCrear WorkerViewMapTabla HTTPRequestPoster ImageResizer JPEGTest GestionDeMapas DATstruct Lugar ProcesarXmlConsulta ProcesarXmlMapa ProcesarXmlMapaSoloContar MiCanvas_servidor Figura B.12: Clases del módulo de gestor de escenarios La clase GestionDeMapas es la principal y contiene funciones para crear los diferentes tipos de cheros necesarios (ver anexo C.2.2) y procesarlos, así como todas las funciones que se requieren desde la pantalla del menú Conguración avanzada de mapas (listar los mapas, descargar uno nuevo, descargar la visualización, etc.). También contiene el listado de APIs que podrán ser usadas para la obtención de los cheros. 110 <<Property>> -path : String -pathTemp : String <<Property>> -listadoMapas : ArrayList<DATstruct> = new ArrayList() -listadoAPIs : ArrayList<String> +GestionDeMapas(p : String) +getTempPath() : String +visualizarMapa(elLugar : Lugar, radio : float, temp : boolean) : String +bajarMapa(alias : String, direccion : String, radio : float, elLugar : Lugar) : String -crearFicheroDAT(name : String, alias : String, direccion : String, radio : float, lat : float, lon : float, m2 : double, n... -crearFicheroXML(name : String, lat : float, lon : float, radio : float) : boolean -createXMLfromAPI(name : String, centroLat : double, centroLon : double, radio : float, textoAPI : String) : boolean -crearFicheroJPG(name : String, lat : float, lon : float, radio : float, temp : boolean) : void +listarMapas() : boolean -buscarArchivosDat() : ArrayList<String> +procesarDat(name : String, path : String) : DATstruct +obtenerBordes(name : String) : Float [] -existeFicheroDAT(name : String) : boolean -existeFicheroXML(name : String) : boolean -existeFicheroJPG(name : String, temp : boolean) : boolean +borrarMapa(name : String) : void +borrarFichero(name : String, sufijo : String) : void -copiarDefaultMaps(path : String) : void -copiarMapa(path : String, name : String) : void -procesarList() : ArrayList<String> +calcularEscaladoRadio(val : float, max : float) : float +calcularEscaladoEspacio(disponible : float, actual : float) : float +calcularM2(elLugar : Lugar, radio : double) : double +sliderValueToRadio(val : int, max : int) : float +nearMeridian(lon : float, radio : double) : boolean +checkMapExists(string : String) : boolean +printMapNames() : void -getAPIs() : ArrayList<String> -leerFicheroAPIs() : ArrayList<String> -crearFicheroAPIs() : void +getListadoMapasString() : String +getNumeroMapas() : int +getNameFromOrdinal(val : int) : String +setPath(p : String) : void +getPath() : String +getListadoMapas() : ArrayList<DATstruct> GestionDeMapas Figura B.13: Detalle de la clase GestionDeMapas 111 La clase DATstruct contiene la estructura de almacenamiento de los mapas, mientras que la clase Lugar tiene la estructura de almacenamiento de las peticiones de obtención de dichos mapas. +name : String +alias : String +direccion : String +radio : float +id : long +tipo : String +lat : float +lon : float +m2 : double +numCaminos : int +numNodos : int DATstruct +id : long +lat : float +lon : float +nombre : String +Lugar(id : long, lat : float, lon : float, nombre : String) Lugar -dom : Document <<Property>> ~lugares : Hashtable +ProcesarXmlConsulta(uri : String) -imprimirResultados() : void -parsearArchivoXml(uri : String) : void -parsearDocumento() : void -obtenerLugar(elemento : Element) : Lugar +getLugares() : Hashtable ProcesarXmlConsulta Figura B.14: Detalle de las clases DATstruct, Lugar y ProcesarXMLConsulta Las clases ProcesarXML... se utilizan para procesar el contenido de los - cheros XML descargados que contienen el listado de resultados de la búsqueda ProcesarXMLConsulta y los datos del escenario en formato OSM . La diferencia entre las clases ProcesarXMLMapa y ProcesarXMLMapaSoloContar radica en que esta última es la utilizada para calcular el número de nodos del escenario y mostrarlo en la tabla de la pantalla del menú, mientras que la primera es la utilizada para cargar los datos al mundo de juego. B.4.4. Módulo de servidor maestro El módulo de servidor maestro contiene las clases necesarias para el funcionamiento del servidor dedicado y del terminal cliente con el que se puede modicar sus parámetros. La clase MasterServer es la encargada de la inicialización del servidor maestro y la conguración del directorio. Recibe conexiones TCP de los terminales e inicia el servidor de la partida cuando es requerido. Para tratar con las conexiones de los terminales, con cada nueva conexión crea un hilo de ejecución con una instancia de la clase HiloMasterServer. Esta clase tiene las funciones necesarias para modicar la conguración de la partida. 112 <<Property>> -nodos : Hashtable <<Property>> -caminos : Hashtable <<Property>> -capas : ArrayList <<Property>> -multipolygons : Hashtable <<Property>> -bordes : Float[] -file : String -tempVal : String #servidor : MiCanvas_servidor -tempNodo : Nodo -tempCamino : Camino -tempMultiPolygon : MultiPolygon +ProcesarXmlMapa(servidor : MiCanvas_servidor, fileName : String) -imprimirResultados() : void -parsearArchivoXml() : void +startElement(uri : String, localName : String, qName : String, attributes : Attributes) : void +characters(ch : char [], start : int, length : int) : void +endElement(uri : String, localName : String, qName : String) : void +getLugares() : ArrayList<LugarInteres> +getNodos() : Hashtable +getCaminos() : Hashtable +getMultipolygons() : Hashtable +getCapas() : ArrayList +getBordes() : Float [] ProcesarXmlMapa Figura B.15: Detalle de la clase ProcesarXMLMapa 113 masterServer menus juego Main Configuracion ConfiguracionP ConfiguracionV HiloMasterServer MasterClient MasterServer Parametros ParametrosConfig MiCanvas_servidor mapas StartClass GestionDeMapas Figura B.16: Clases del módulo de servidor maestro 114 La clase MasterClient es la encargada de realizar la conexión mediante TCP con el servidor maestro y tiene las funciones necesarias para obtener y modicar la conguración actual de las partidas que inicie dicho servidor. Si los parámetros usados así lo requieren, tanto MasterServer como MasterClient son instanciadas desde la clase StartClass, que es la clase inicial de la aplicación cuando esta no se ejecuta como Applet . B.4.5. Módulo de servidor estadístico El módulo de servidor estadístico contiene las clases necesarias para el despliegue del servidor de recogida de estadísticas y el envío y recepción de éstas. La clase StatServer se encarga de iniciar el proceso y escuchar peticiones de conexión, creando instancias de la clase HiloStatServer cuando dichas peticiones de conexión son aceptadas. La clase HiloStatServer contiene funciones para recibir los diferentes tipos de estructuras de estadísticas por parte de los servidores. Por último la clase EnvíoEstadísticas es una clase en la cual se denen métodos (estáticos) para que los servidores puedan enviar los diferentes tipos de estadísticas a los servidores de recogida de estadísticas. B.4.6. Módulo de estadísticas El módulo de estadísticas contiene las clases que permiten la creación de las diferentes estructuras de estadísticas (de aparcamiento, de juego y de VESPA) y la estructura que contiene el resumen de la conguración actual de la partida. Además también contiene las funciones necesarias para almacenar en cheros dichas estructuras de forma legible al usuario. Para cada tipo de chero que se desea generar cuando las estadísticas estén activadas, se tiene una clase en la que se contiene su estructura TADEstadisticasAparcamiento, TADEstadisticasJuego, EstadisticasVespa (EV) y CurrentCongInfo (CCI), para estadísticas de aparcamiento, de la partida, de VESPA y para el resumen de la conguración respectivamente. Para cada uno de estos tipos se tiene una clase con las funciones necesarias para limpiar el directorio donde se almacenan los cheros y crear el chero, además de los métodos llamados desde el juego y mediante los cuales se calculan las estadísticas. Las estadísticas de aparcamiento tienen dos clases asociadas TADEstadisticasAparcamiento y TADEstadisticasAparcamientoTC cuya diferencia es que la primera es llamada por los jugadores humanos mientras que la última está ideada para vehículos del tráco, por lo que la función que incluyen para anotar un apar115 StatServer Main +host : String +port : int +CCI : int +EA : int +EATC : int +EVP : int +EV : int +EVR : int +EJ : int -sendUUID(socket : Socket, uuid : UUID) : void -sendType(socket : Socket, type : int) : void +enviarCCI(cci : CCI, uuid : UUID) : void +enviarEA(ea : ArrayList<TADEstadisticasAparcamiento>, uuid : UUID, tc : boolean) : void +enviarEV(ev : EV, uuid : UUID, player : boolean) : void +enviarEVR(evr : EV, uuid : UUID) : void +enviarEJ(ej : ArrayList<TADEstadisticasJuego>, uuid : UUID, tc : boolean) : void EnvioEstadisticas -s : Socket -path : String +HiloStatServer(socket : Socket, path : String) +run() : void +receiveCCI(cliente : Socket) : CCI +receiveEA(cliente : Socket) : ArrayList<TADEstadisticasAparcamiento> +receiveEV(cliente : Socket) : EV +receiveEJ(cliente : Socket) : ArrayList<TADEstadisticasJuego> HiloStatServer -continueRunning : boolean -sv_socket : ServerSocket -port : int -path : String +StatServer() +run() : void -mainLoop() : void -initTcp(port : int) : void +closeTcp() : void +aceptarCliente() : Socket -createFolder() : void StatServer +main(args : String []) : void StartClass Figura B.17: Clases del módulo de servidor estadístico 116 estadisticas menus CurrentConfigInfo CCI EstadisticasAparcamiento EstadisticasAparcamientoTC EstadisticasJuego TADEstadisticasJuego EstadisticasVESPA EV TADEstadisticasAparcamiento Parametros mapas GestionDeMapas DATstruct Figura B.18: Clases del módulo de estadísticas +StatisticsOn : boolean -pathName : String +createCleanFolder(uri : String, date : String) : void +createFolder(path : String, uuid : String) : void +writeFile(p : Parametros, mDJ : byte, numPlayers : int, timeElapsed : int, mapData : DATstruct) : void +writeFile(cci : CCI, path : String, uuid : String) : void -protocol2String(p : int) : String +getPath() : String CurrentConfigInfo Figura B.19: Detalle de la clase CurrentCongInfo (CCI) 117 conexion juego Cliente GestorConexiones GestorSnaps GestorTCPCliente TCP_cliente <<Interface>> TCP_comun TCP_master_related TCP_servidor UDP_cliente UDP_servidor MiCanvas_servidor red util MiCanvas_cliente EventoGUI FullSnapshot InputSnapshot Snapshot SnapYBueno Figura B.26: Clases del módulo de gestor de conexiones (1 de 2) AcumuladorActor AcumuladorAmbulance AcumuladorCar AcumuladorFlag AcumuladorHumo AcumuladorLO AcumuladorLRP AcumuladorObstaculo AcumuladorParking AcumuladorPlayer AcumuladorRedCar AcumuladorTrafficCar Figura B.27: Clases del módulo de gestor de conexiones (2 de 2) 124 +timeoutTime : int +blockTime : int -socket : DatagramSocket -cliente : MiCanvas_cliente -tiempoUltimaRecepcion : long +UDP_cliente(cliente : MiCanvas_cliente) +initClient() : void +closeClient() : void +sendInputSnapshot(inputSnapshot : InputSnapshot) : void +receiveSnapshot() : Snapshot +cl_conexionPerdida() : boolean UDP_cliente +InetAddress : InetAddress +port : int +lastAckState : int +lastState : int -oldStates : HashMap +Cliente(InetAddress : InetAddress, port : int, lastAckState : int) +getOldState(sequence : int) : Snapshot +addOldState(lastState : Snapshot, sequence : int) : void +setLastAckState(lastAckState : int) : void +setLastState(lastState : int) : void Cliente Figura B.28: Detalle de las clases UDP_cliente y Cliente partida y de proporcionarles el estado inicial de la partida ( FullSnapshot ). Respecto a las clases que se usan durante la partida, FullSnapshot, Snapshot e InputSnapshot contienen la estructura de los paquetes de datos transmitidos entre clientes y servidor. La primera contiene el estado inicial del juego, es decir, los elementos estáticos que no van a cambiar durante el trascurso de la partida y que por lo tanto solo serán necesarios de enviar cuando el jugador se conecte. La segunda contiene el estado actual del juego: los elementos dinámicos que pueden variar (p.ej. los vehículos o los objetivos). La tercera contiene los eventos de teclado recogidos en el cliente y que deben transmitirse al servidor en cada ciclo. La clase SnapYBueno es una simple estructura formada por un Snapshot y un valor booleano, que indica si es correcto según el sistema de control de ujo. Se usa en el cliente para almacenar los snapshots pendientes de procesar. La clase GestorSnaps es la encargada de realizar este control de ujo de paquetes. La clase EventoGUI contiene la estructura utilizada para los mensajes que se muestran en pantalla al jugador cuando ocurren ciertos eventos, y contiene también los métodos necesarios para su creación. Dentro de las clases usadas durante la partida también se encuentran los acumuladores , que son clases creadas para solucionar el problema causado por el envío de únicamente actores cercanos (ver anexo C.6.5). Estas clases están contenidas en el paquete juego.red.acumuladores y se dispone de una clase por cada tipo de objeto que se ha de enviar solo en ciertas ocasiones. 125 +DURACION : int +text : ArrayList<String> +length : int +EventoGUI() +EventoGUI(l : int) +addLine(t : String) : void EventoGUI +bufferRecibidos : ArrayList<SnapYBueno> +ultimoBueno : Snapshot +GestorSnaps(ultimoBueno : Snapshot) -setUltimoBueno(ultimoBueno : Snapshot) : void +addRecibido(ultimoRecibido : SnapYBueno) : void +esperar() : boolean +removeOne() : SnapYBueno +checkSnapshot(newState : Snapshot) : boolean -sequence_more_recent(s1 : int, s2 : int) : boolean GestorSnaps Figura B.29: Detalle de las clases GestorSnaps y EventoGUI +changed_angle : boolean +changed_globalX : boolean +changed_globalY : boolean +changed_speed : boolean +changed_currentFrameServidor : boolean +changed_frameSpeed : boolean +changed_tServidor : boolean -secuenciaReseteo : Integer +AcumuladorActor() +acumularCambios(a : Actor) : void #resetearCambios() : void +markForReset(sequence : int) : void -isMarkedForReset(sequence : int) : boolean +resetIfRequired(sequence : int) : void AcumuladorActor Figura B.30: Detalle de una clase acumulador 126 B.4.11. Módulo de física El módulo de física contiene las funciones y estructuras que permiten realizar tareas como la detección de colisiones. util fisica +Position2D() +Position2D(a : float, b : float) +Position2D(v : Position2D) +isZero() : boolean +parallelComponent(unitBasis : Position2D) : Position2D +perpendicularComponent(unitBasis : Position2D) : Position2D +dot(v : Position2D) : float +rotate(theta : float) : Position2D +translate(dx : float, dy : float) : Position2D +addition(v : Position2D) : Position2D +subtraction(v : Position2D) : Position2D +multiplication(s : float) : Position2D +division(s : float) : Position2D +length() : float +lengthSquared() : float +interpolate(alpha : float, x0 : Position2D, x1 : Position2D) : Position2D +distance(a : Position2D, b : Position2D) : float +normalize() : Position2D +intermediatePoint(a : Position2D, b : Position2D) : Position2D +writeExternal(out : ObjectOutput) : void +readExternal(in : ObjectInput) : void Position2D +detectCollision(B1 : PhysicsRectangle, B2 : PhysicsRectangle) : boolean -IntervalDistance(MinA : float, MaxA : float, MinB : float, MaxB : float) : float Fisica +a : float +b : float +FloatPair(a : float, b : float) FloatPair +depth : float +normal : Position2D CollisionInfo +v1 : Position2D +v2 : Position2D +Edge(v1 : Position2D, v2 : Position2D) Edge +VertexCount : int = 4 +EdgeCount : int = 2 +edges : Edge[] = new Edge[EdgeCount] +vertices : Position2D[] = new Position2D[VertexCount] +vertices[] : Position2D[] = new Position2D[VertexCount] +edges[] : Edge[] = new Edge[EdgeCount] +PhysicsRectangle(center : Position2D, width : int, height : int, angle : float) +projectToAxis(Axis : Position2D) : FloatPair PhysicsRectangle * +vertices[] 1 +v1 1 +v2 1 +nor... * +edges[] Figura B.31: Clases del módulo de física La clase Fisica realiza la detección de colisiones entre actores (no con elementos del terreno) y hace uso de la clase PhysicsRectangle que contiene los ejes y vértices que representan al actor y tiene funciones para proyectar dicha representación sobre los ejes (necesario para calcular la colisión según el teorema Separating Axis theorem (ver anexo C.4.2). 127 B.4.12. Módulo de inteligencia articial El módulo de inteligencia articial realiza los cálculos de path-nding (paquete astar) y del control de la conducción del vehículo. juego util Position2D MiListaSincronizada actores MiCanvas_servidor inteligencia terreno Nodo Car Camino Peticion NodoyNodo Resultado ObstaculoEsferico PathWay MapPointToPathReturnValue SteeringBehaviors ResultCNAP SteeringYDesired astar HiloPathFinding AStarAlgorithm AStarNode AStarNodeComparator listaOut listaResultadosIA listaPeticionesIA listaIn me steer pathWay cameFrom camino camino target source node Figura B.32: Clases del módulo de inteligencia articial Dentro del paquete astar se encuentra la clase AStarAlgorithm que, mediante el uso de las clases AStarNode (representación de un nodo) y AStarNodeComparator (comparador de nodos), realiza una búsqueda A* sobre los nodos que forman los caminos del terreno para encontrar la ruta más corta entre dos puntos. Ésta clase es llamada desde la clase HiloPathFinding, que tiene un hilo de 128 ejecución propio y recibe a través de la clase MiListaSincronizada peticiones (clase Peticion) de path-nding, las computa y cuando el resultado está listo devuelve el resultado (clase Resultado) a través del mismo medio. Respecto al control de la conducción, las clase más importante de las que intervienen es SteeringBehaviors, que contiene los métodos invocados desde el vehículo para la realización de los diferentes comportamientos indicados en [17] y en su mayor parte desarrollados en OpenSteer 2 (ver C.5.1). SteeringYDesired es una estructura donde se tiene el vector que indica el giro a realizar junto al vector que indica la dirección a la que se encuentra el objetivo. ObstaculoEsferico contiene una posición en dos dimensiones y un radio y se asocia con las entidades que deben ser esquivadas por los diferentes comportamientos desarrollados. Por último PathWay, MapPointToPathReturnValue y ResultCNAP son clases que se han obtenido de la implementación de la librería OpenSteer y son usadas por los métodos que implementan los diferentes comportamientos de control del vehículo. B.4.13. Módulo cliente Este módulo se compone de todos los elementos que intervienen en la parte cliente de la aplicación y no encajan en el resto de módulos. En la gura B.33 se da una vista general de la interacción de la clase MiCanvas_cliente con el resto de clases del módulo y también las relaciones con el resto de módulos que no hayan sido vistas todavía. La clase principal es MiCanvas_cliente y contiene métodos para el pintado del mundo de juego y la interfaz gráca de usuario, el tratamiento de red (incluyendo la interpolación, extrapolación y predicción), la captura de eventos del teclado, el manejo de las entidades locales, las acciones realizadas en el cliente para liberar de gasto de procesamiento al servidor (cálculo de aparcamientos cercanos, etc.). Dentro de este módulo hay muchas otras clases de apoyo, la mayoría en el paquete juego.otros. Una de estas clases es RadarVespa, que permite representar el radar y contiene métodos para pintar en él diversos tipos de elementos. Una clase asociada a ésta es MiniMapEvent, que tiene la representación de los eventos proporcionados por VESPA con la mínima información necesaria (ya que será transmitida a través de la red). La clase Flecha contiene la estructura y funciones necesarias para calcular y mostrar en pantalla las echas que indican la posición de los objetivos y enemigos respecto del jugador. 2 http://opensteer.sourceforge.net/ 129 MiCanvas_cliente otros actores red rondaYObjetivos <<Interface>> Stage terreno util Actor ActorFX <<Interface>> BasicActor Car OnlyPosition Player Flecha <<Enum>> TipoObjetivo MiniMapEvent PosicionPlayerSinPrediccion RadarVespa ResourceCache SpriteCache EventoGUI FullSnapshot InputSnapshot Snapshot ExplicacionRonda ExplicacionRondaSalaDeEspera ModosDeJuego Opciones Tarea Camino DanyoVelocidadYCalle MultiPolygon Nodo Angulos SnapYBueno TextStroke Figura B.33: Clases del módulo de cliente 130 -mapWidth : float -mapHeight : float -maxA : int -maxB : int -scale : float -cliente : MiCanvas_cliente -a : int -b : int -offsetA : int -offsetB : int -comienzoX : int -comienzoY : int #spriteCache : SpriteCache +RadarVespa(c : MiCanvas_cliente, maxWidth : int, maxHeight : int, width : float, height : float, comienzoX ... +paintBackground(g : Graphics2D) : Rectangle +paintEvents(g : Graphics2D, listaPuntitos : List<RadarRepresentationOfEvent>) : ArrayList<MiniMapEvent> +paintTooltipsEvents(g : Graphics2D, lista : ArrayList<MiniMapEvent>, mouseX : int, mouseY : int) : void -drawToolTip(g : Graphics2D, x : int, y : int, text : String) : void +paintOnlyMyPlayer(g : Graphics2D, jugador : Player) : void +paintGasolineras(g : Graphics2D, gasolineras : ConcurrentHashMap) : void +paintPuestosPerritos(g : Graphics2D, puestosPerritos : ConcurrentHashMap) : void +paintLugares(g : Graphics2D, lugares : ArrayList<Tarea>) : void +paintOff(g : Graphics2D) : void RadarVespa Figura B.34: Detalle de la clase RadarVespa +x : int +y : int +width : int +height : int +typ : RadarRepresentationOfEvent +MiniMapEvent(x : int, y : int, w : int, h : int, typ : RadarRepresentationOfEvent) +contains(mx : int, my : int) : boolean +typ2String(cliente : MiCanvas_cliente) : String MiniMapEvent Figura B.35: Detalle de la clase MiniMapEvent 131 -angle : short -spriteNames : String[] -currentFrame : byte -width : int -height : int -objetivo : Object -jugador : Player -red : float -green : float -blue : float -tipoActor : TipoObjetivo -spriteCache : SpriteCache -attribute : SpriteCache +Flecha(cliente : MiCanvas_cliente, j : Player, color : Color) -setSpriteNames(names : String []) : void +paint(g : Graphics2D) : void +setObjetivoA(actor : OnlyPosition) : void +setObjetivoL(l : LugarInteres) : void +setObjetivoD(c : Float) : void -calcularAngulo() : void Flecha Figura B.36: Detalle de la clase Flecha B.4.14. Módulo servidor Este módulo se compone de todos los elementos que intervienen en la parte servidor de la aplicación y no encajan en el resto de módulos. En la gura B.37 se da una vista general de la interacción de la clase MiCanvas_servidor con el resto de clases del módulo y también las relaciones con el resto de módulos que no hayan sido vistas todavía. La clase principal es MiCanvas_servidor, que contiene métodos para el tratamiento de red, inicialización del mundo de juego, cálculo de puntuaciones e inicialización y nalización del servidor. Esta clase interactúa con el resto de módulos previamente citados. B.5. Game Loop (bucle de juego) El game loop es una secuencia presente en todos los juegos que generalmente consiste en obtener los comandos del jugador, actualizar el estado del juego, realizar las tareas de la IA, reproducir los efectos de sonido y pintar el juego. 3 Esta secuencia se ejecuta innitas veces hasta que se acabe la partida. 3 http://www.koonsolo.com/news/dewitters-gameloop/ 132 <<Interface>> Stage MiCanvas_servidor rondaYObjetivos terreno actores red inteligencia otros fisica ExplicacionRonda ExplicacionRondaSalaDeEspera <<Interface>> IObjetivos ModosDeJuego ObjetivosAparcar ObjetivosRally ObjetivosSupervivencia ObjetivosTareas Opciones Ronda Tarea Camino DFSAlgorithm LugarInteres <<Enum>> TipoLugar Nodo PosYAngle Actor <<Interface>> BasicActor Car Parking Player HistoricoJugador EventoGUI FullSnapshot Snapshot HiloPathFinding SpriteCache Fisica FloatPair CollisionInfo Edge PhysicsRectangle Figura B.37: Clases del módulo de servidor 133 236 Vanet-X: A Videogame to Evaluate Information Management in Vehicular Networks Sergio Ilarri IIS Department University of Zaragoza Zaragoza, Spain [email protected] Eduardo Mena IIS Department University of Zaragoza Zaragoza, Spain [email protected] V´ ıctor R´ ujula IIS Department University of Zaragoza Zaragoza, Spain [email protected] ABSTRACT Vehicular Ad Hoc Networks (VANETs) are attracting considerable research attention, as they are expected to play a major role for Intelligent Transportation Systems (ITS). Thus, according to a recent survey by ABI Research1, about 62% of new vehicles will be equipped with vehicle-to-vehicle (V2V) communications by 2027. Vehicular networks offer new opportunities for the development of interesting mobile applications for drivers, but at the same time they also bring challenges from the data management point of view. Thus, for example, techniques should be developed to estimate the relevance of the information exchanged among the vehicles and to propagate the relevant data in the network efficiently and effectively. As testing the proposals in a real large-scale scenario is impractical, simulators are often used. In this paper we present Vanet-X, an online multiplayer driving videogame that we have developed to help in the difficult evaluation task of data management strategies for VANETs. The idea behind the proposal is to exploit the potential of players around the world driving vehicles in the videogame to effortlessly collect data that can be used to extract some conclusions and fine-tune the proposed data management strategies. So, for example, the videogame allows to evaluate if a certain data management strategy is able to provide useful information to the driver/player (i.e., if the presented information represents an advantage for him/her). We argue that this videogame can be a good complement for existing simulators. As a proof of concept, we have performed some preliminary tests that show the potential interest of the proposal. 1. INTRODUCTION The widespread availability of mobile devices and the development of wireless communication technologies (such as Wi-Fi, WAVE, etc.) have encouraged the development of 1http://www.abiresearch.com/press/ v2v-penetration-in-new-vehicles-to-reach-62-by-202. services for drivers within the context of Intelligent Transportation Systems (ITS). In particular, Vehicular Ad Hoc Networks (VANETs) have become an attractive research area [1, 14, 15, 20, 24, 26, 30]. In these vehicular networks, the vehicles can exchange information directly by using short-range wireless communication technologies. This decentralized architecture provides some advantages over other solutions such as the use of 3G communications: e.g., no need of an infrastructure, quicker transmission of safetyrelated data in the vicinity, localized communications without the need of a centralized server, and free of charges (which also encourages the participation of peers in the network). Numerous types of events can be relevant for drivers (e.g., accidents, traffic congestions, an ambulance asking the right of way, available parking spaces, etc.). These events can be exchanged in the vehicular network and stored locally by the vehicles. Then, a query processor can periodically evaluate the interest of those events and decide if they should be shown to the driver; there may be implicit queries (e.g., information about an accident in the direction of travel will be relevant for any driver) and explicit queries (e.g., a driver may indicate his/her interest in finding an available parking space or in receiving information about other specific types of events). However, although VANETs offer interesting opportunities for the development of data services for drivers, they also bring new challenges. Thus, several difficulties arise from the point of view of data management [5]. As an example, estimating the relevance of events in order to disseminate them effectively and efficiently in the network is a challenge [2]. Similarly, disseminating information about a scarce resource (e.g., an available parking space) to many vehicles can lead to competition situations among them to try to reach the resource [7]. As a final example, the relevance of events must also be considered in order to decide if a specific event received by a vehicle should be shown to the driver or not [3]. A big challenge is how to evaluate the data management techniques proposed. Evaluating them in a real scenario with a significant number of vehicles is simply impractical and expensive. Therefore, simulations are frequently used in this field. However, even with simulations the evaluation task can be very time-consuming. For example, many proposals depend on a number of parameters that can be fine-tuned for a given scenario (e.g., see [2, 31]), and determining a good choice of parameters for general evaluation is quite challenging. On the other hand, crowdsourcing strategies where users play the role of drivers could help to 1 introduce human behavior and facilitate new tests initiated by the users themselves. So, in this paper we propose a complementary approach that can be used in conjunction with the use of simulators. In particular, we argue that we can benefit from players having fun with a driving game to easily collect interesting data that can be used to extract some conclusions and fine-tune the proposed data management strategies. The videogame is inspired by the classic videogame Rally-X (http://www. klov.net/game_detail.php?game_id=9259, videogame released in 1980) but it is a new development, with different goals, game modes, and spirit. So, the basic idea is that the vehicles can receive information through the vehicular network and different data management techniques can be plugged in the videogame (e.g., different data dissemination strategies). Data received from other vehicles, if evaluated as interesting by the local query processor in the car, are shown on a radar and can provide a competitive advantage to the player. During the game, a variety of data are collected (e.g., number of messages received by the vehicles, network overhead, time required by the vehicles to complete their goals in the game, etc.), that can be analyzed later. So, while playing, players contribute to collect data for a variety of scenarios, and these data can be exploited to evaluate the effects of particular data management strategies. The structure of the rest of this paper is as follows. In Section 2 we describe the high-level architecture of the videogame and its features. In Section 3 we summarize the main behaviors implemented for the computer-managed vehicles. In Section 4 we present some basic aspects about the way the data are collected for later analysis. In Section 5 we present the results of the first experiments that we have developed as a proof of concept. In Section 6 we present some related work. Finally, in Section 7 we present our conclusions and some lines of future work. 2. ARCHITECTURE AND FEATURES Vanet-X is a car videogame that can be played by multiple players connected to the Internet (see Figure 1 for a snapshot showing parking spaces). 2.1 Main Features We summarize some features of the game as follows: Figure 1: Cars and parking spaces in Vanet-X •It is implemented in Java as a Java applet, so only a Java Virtual Machine and a browser is needed to play. A desktop application version is also available. •Both real (human) and computer-controlled players can participate in the game. Human players can join a game through the Internet. •The game can be configured to execute on a server and create new games when necessary. Alternatively, the computer of any user can play the role of a server and start a new game that other users can join. •Any real map can be used in the game, by selecting and downloading the data of the desired area from OpenStreetMap (http://www.openstreetmap.org/). •To increase the playability, real maps are combined with some extra elements, such as enemy cars, smoke emission devices to disturb enemies (see Figure 2), evolution of events in game time rather than in real-world time, higher maximum speeds for cars controlled by humans, when the driver has a task to go to a certain building he/she has to park nearby and then go by foot to the destination (he/she will be a vulnerable target for enemy cars, that will try to hit him/her, as shown in Figure 3), the car can get damaged and be repaired by paying a certain price (points accumulated during the game), there is infinite or limited fuel depending on the game mode (requiring refueling in a petrol station when running out of fuel in the second case), etc. Figure 2: Trying to escape from an enemy vehicle Figure 3: Driver going by foot •A wide range of game modes is available (see Table 1). Thus, for example, we offer games where the goal is to collect some items along the roads, and task-based 2 games where the players have to complete a series of goals in sequence (with tasks such as parking the vehicle, going to a certain building/business or address, etc.) as soon as possible to win the game. As shown in the table, some game modes can be cooperative, competitive, or both. For the tasks implying going to a certain location, the task may require reaching that location with the car, park and then get there by foot, or just park as near as possible (in this last case, the score for completing the task will be inversely proportional to the distance between the parking location and the final destination). Competitive games involves from 1 to 4 teams in the game, being the winner the team that obtains more points during the game. Game mode Multiplayer mode Inmortal Possibility to get out of the car and walk Infinite fuel Capture the flag (capture 5 flags) cooperative no no configurable competitive Capture the enemy cars (1 or more) cooperative yes no no competitive Solve tasks (1-3 tasks) cooperative no yes configurable competitive Survival (1 or 2 tasks) cooperative no yes configurable competitive Park (find one available parking spot) competitive yes yes no Table 1: Summary of game modes •Some default data management strategies, inspired by the work performed in the VESPA project [2, 3, 4, 6, 7], have been implemented. Different tuning parameters can be modified through the graphical user interface of the videogame (see Figures 4 and 5). Moreover, the design of the videogame allows an easy integration of other data management alternatives. Figure 4: Data management: basic options •There is a “radar” (e.g., on the right part of Figure 2 we show a basic radar, and on the right part of Figure 1 a radar in debug mode that shows some extra elements about the scenario) that can provide some information to the players. For example, a player can see the following on the radar: his/her location, the petrol stations, and the destination location (if any). Besides, if the option to use a data sharing strategy for that vehicle has been enabled, it will also show data about interesting events received from other vehicles, such as free parking spaces, enemy vehicles, items to Figure 5: Data management: advanced options pick up (e.g., flags in Figure 6), priority vehicles like ambulances, etc. Figure 6: Picking up flags during the game From a more technical point of view, we have used the Java programming language to develop the video game. Besides, some auxiliary libraries have been useful. For example, we use Apache Xerces2 Java (http://xerces.apache. org/#xerces2-j) to extract data from the XML files obtained from OpenStreetMap, JLayer (http://www.javazoom. net/javalayer/javalayer.html) to decode and reproduce MP3 files for the game music, Guava-12.0 (https://code. google.com/p/guava-libraries/), etc. 2.2 Basic Architecture The basic architecture of the videogame is presented in Figure 7 (the part concerning the collection of statistics about the game is not shown here, as it will be described in Section 4). At a high-level, we can briefly describe the main components as follows: •Aclient application receives commands from the player, sends them to the server, and receives from the server information about the objects that should be rendered on the screen (see Figure 8). •The server receives the input from the clients, updates the current status of the game (e.g., by considering the movements performed by the vehicles and the tasks that they complete), and generates new goals and events as needed (see Figure 9). The server is multithreaded, with a thread per vehicle that performs a 3 Figure 7: Basic architecture of Vanet-X Figure 8: Basic functioning of a client basic cycle of “while a vehicle is alive, perform actions and check for potential collisions”. Figure 9: Basic functioning of the server •An interface IDataManagementStrategy declares the methods that should be implemented by a data management strategy to allow its integration with the videogame (e.g., a method to define the types of events that are interesting for the driver, a method to generate an event, etc.). •Another interface IVehicle is implemented by the vehicles to allow interacting with them (e.g., to obtain a reference to the data manager in the vehicle or to obtain information about the GPS location). Any data management strategy can potentially be integrated in this framework, as long as it implements the interface IDataManagementStrategy and calls the appropriate methods to inform the vehicles (interface IVehicle). So, we can easily plug in different alternative data management techniques for testing. 3. BEHAVIORS OF THE VEHICLES We have implemented several behaviors for the vehicles controlled by the computer, which adapt the steering behaviors proposed in [23]. In particular, we consider the following basic behaviors: •Seek implies directing the vehicle towards a certain static target, by adjusting its direction and speed. •Flee is the opposite behavior to Seek, as it implies getting as much further as possible from the target. •Pursuit is similar to Seek, but in this case the target is a moving object. So, the expected movement of the target is estimated, to try to catch it. •Evasion is the opposite behavior to Pursuit (i.e., based on Flee instead of Seek). •Arrival implies the progressive reduction of speed as the vehicle approaches the target. •Obstacle avoidance provides vehicles with the ability to dodge vehicles and other obstacles. •Wander generates a random trajectory, to represent a vehicle traveling around with no clear objective. This is useful, for example, to represent a vehicle that is searching for an available parking space in the vicinity. •Path following allows a vehicle to circulate within the boundaries of a certain path. •Unaligned collision avoidance is a behavior that tries to avoid the collision of vehicles moving in different directions. Thanks to this behavior, vehicles can estimate a potential collision risk with other vehicles in the near future, to try to avoid it. Of course, all the vehicles exhibit the whole set of behaviors at the same time, applying a priority ordering in case several behaviors could be applied at the same time and are in conflict to each other. Based on the previous basic behaviors, we have defined the schema of a normal behavior for different types of vehicles: enemy cars (that try to catch the players or flee from the players, depending on the game mode), ambulances (as representatives of emergency vehicles which may ask the right of way), and traffic cars (that represent neutral cars in the game). As an example, the basic behavior of traffic cars is shown in Figure 10. 4 Figure 10: Basic behavior of a traffic car 4. DATA COLLECTION AND EXPLOITATION In this section, we summarize the strategy applied for data collection during the game and the corresponding exploitation of results. If a certain configuration option that activates the collection of statistics during the game is enabled, several data are collected: data about the scores obtained by the players, the time needed by vehicles (the ones controlled by humans as well as those managed by the computer) to perform certain tasks (such as parking), and other measures about the performance of the data management strategy applied (e.g., events created, events that are considered relevant by each vehicle, etc.). When the game ends, all these data are stored in several files on the game server, along with a file that contains information about all the configuration parameters used in that game (e.g., game mode, configuration parameters used for the data management strategy considered, the wireless communication range simulated, etc.). To centralize the data collected, it is possible to set up a Statistics Server, which is a process executing continuously on a certain computer. In this way, the clients playing the game automatically connect to the Statistics Server when a game ends, in order to communicate the statistics collected during the game. Besides, it is possible to connect to the Master Server by using a terminal client (called Statistics Client) that allows seeing and modifying the configuration parameters as well as retrieving the statistics files generated. Another option is to avoid the use of a Statistics Server and collect the statistics in the computer that plays the role of a server for a game. If we consider configuration settings where there is a predefined game server and all the clients connect to it to start a new game or join an existing game, this option also keeps the statistics in a single location. However, if there are several game servers then the statistics would have to be centralized manually. Figure 11 provides an overview of the way the different components of the game, and particularly the Statistics Server, are distributed in a network. Notice that we actually distinguish between a Master Server and a Game Server. The Master Server is executing on the server machine and a client first connects to it (so, it is the entry point for clients); then the Master Server checks if a Game Server is available and if not it creates one; finally, it returns the port number of its Game Server to the client, as the client will interact with the Game Server during the game. It should be noted that, as we collect information about the performance of human players, the skills of those players Figure 11: Deployment of components in a network with the game will have an impact on the results and this has to be taken into account when exploiting the results. Indeed, directly comparing the achievements of several human players without considering their game skills could lead to wrong conclusions. For example, player1 without a data sharing system could perform better than player2 with a data sharing system, but we should not necessarily conclude that the use of such a data sharing system is harmful. In other words, we should always compare players with the same skills. For this reason, each human player is assigned a certain skill level (which may change along time, as the player improves his/her performance) and the statistics about players are tagged with the skill level corresponding to that player. Besides, players that have a skill level below a certain threshold are (by default) not allow to participate in games with collection of statistics enabled, as performance data about them are assumed to be unreliable and besides their clumsiness could interfere with the normal development of the game. The skill level of a player is computed based on his/her ability to complete missions in the game (tasks per time unit). 5. EXPERIMENTAL EVALUATION We have performed a few preliminary experiments to evaluate the interest of our proposal. As a use case for testing, we focused on the case of available parking spaces, as these are events that represent scarce resources, which implies additional challenges for data management (i.e., the competition among vehicles should be minimized). 5.1 Data Management Strategies As a data sharing strategy for the vehicles, we considered the following options. 5.1.1 VESPA-P: VESPA With No Reservation First, we adapted the proposal in [2], developed in the context of the system VESPA (Vehicular Event Sharing with a mobile P2P Architecture) [4, 6], which is based on the computation of an Encounter Probability (EP). The EP between a vehicle and an event estimates the likelihood that the vehicle will meet the event, based on geographic computations that estimate the spatio-temporal relevance of the event. For example, the relevance decreases 5 with the distance between the event and the vehicle, with the time since the event was generated (e.g., consider the case of information about an available parking space, which can be unoccupied only for a limited amount of time), and the direction of the vehicle (e.g., if it is approaching the event or not). In particular, the directions of both the vehicle and the event are estimated and several penalty coefficients (α,β,γ, and ζ) are used to weigh the importance of four estimated parameters: the minimum distance to the event over time (∆d), the time until the closest position to the event (∆t), the age of the event at the closest position (∆g), and the angle between the vehicle and the event (c). So, when a vehicle receives an event it computes its EP and disseminates the event again if the computed EP exceeds a certain dissemination threshold (DT ). The intuition is that vehicles should disseminate data that are relevant for them (as those data are also probably relevant for the neighboring vehicles). Two other thresholds are managed: the storage threshold (ST ) and the relevance threshold (RT). The ST determines the minimum value of the EP for an event to be stored locally in the vehicle, and the RT the minimum value needed to show the event to the driver. Besides, the proposal in [2] proposes a contention-based approach for data dissemination in order to limit the network overhead in the dissemination of messages (basically, when there are several candidate vehicles to re-disseminate an event, the message will be disseminated only by the vehicle located further away from the vehicle that disseminated the message previously). Several parameters are used in the protocol, such as D(the maximum time to wait before rediffusing) and D0(time to wait for an acknowledgement that a message sent previously was received by some other vehicle). 5.1.2 VESPA+P: VESPA With Reservation Protocol Communicating the availability of a single parking space to many vehicles could lead to an unfruitful competition among the vehicles to try to reach the same parking space, leading to dissatisfaction of the drivers and parking times that could even exceed those that would be obtained if no data sharing system were used. For this reason, the work presented in [7] proposed an enhancement to the previous approach VESPA-P for the case of scarce resources such as parking spaces. It provides an allocation protocol that coordinates a procedure that ensures that the information about an available parking space is communicated to a single interested vehicle. 5.1.3 Blind: No Data Sharing Finally, we also considered an approach where no data sharing strategy is used. In this case, the vehicles receive no information and the only data available for the drivers are what they see with their own eyes. For vehicles trying to find available parking spaces, this will lead to a blind search. 5.2 Experimental Settings The basic configuration of the videogame for the experimental evaluation is as follows. The communication range considered for the vehicles is 200 meters and a maximum of 50% of the vehicles are assumed to be equipped with a data sharing application. The penalty coefficients used to compute the EP for VESPA are: α=1/1500 (∆d≤500 meters), β=1/180 (∆t≤60 seconds), γ=1/360 (∆g≤120 seconds), and ζ=1/270 (c≤90◦); these are parameters that can be considered for a “medium” (not small, not large) dissemination area, according to [2]. The RT and the DT are both set to 75%, and the ST is 60%. The query processor on each vehicle re-evaluates the relevance of the events received with a refreshment period of 2 seconds, showing on the radar the events that are considered relevant. For the dissemination protocol, Dis set to 1 second and D0to 2 seconds. 5.3 Experimental Results We have simulated a varying number of vehicles moving in an area of 1 squared kilometer around the street “Sophie Oury” in the city of Valenciennes (France). In this scenario, we measured the time needed by the vehicles to find free parking spaces near certain destinations. In Figure 12 we show the reduction on the average time needed by a human player to find an available parking space near the target. The experimental results show the interest of sharing data among the vehicles (with both VESPA-P and VESPA+P), as these data can later be shown on the radar to provide interesting information to the drivers. Besides, according to these results, using a reservation protocol to avoid the competition problem (VESPA+P) is particularly beneficial. Figure 12: Time to park by a human In Figure 13 we compare the performance of human players (vehicles controlled by humans) and computer players (vehicles controlled by the computer), by showing the reduction on the average time needed to find an available parking space near the target when using VESPA+P. According to these experimental results, we can see that the human players get more benefit from the use of the data sharing strategy. The difference may be due to the way the artificial intelligent behavior of the computer vehicles is implemented. Figure 13: Time to park: human vs. computer The experimental results obtained correspond to data collected during a total of 14 hours playing the videogame (about 400 parking actions by the human player during this 6 game time). The results are consistent with our intuition and with other experimental results obtained previously by using a simulator. Nevertheless, more tests are needed to validate the results and evaluate other scenarios. For example, we started to obtain some first preliminary results with games played by more than one human player. It is also interesting to perform experiments with other types of events (e.g., accidents, obstacles on the roads, etc.); with information about them, drivers could try to avoid those hazards and so decrease the total travel time. 6. RELATED WORK As far as we know, this is the first attempt to develop a videogame whose hidden purpose is to help with the evaluation of information management strategies for vehicular networks. Nevertheless, the idea of trying to benefit from human actions to improve or evaluate a system is not new. Exploiting the power of people to perform large-scale tasks that are costly, time-expensive, or hard, is called crowdsourcing [33]. For example, mCrowd [32] benefits from sensors available on iPhone devices to perform collaborative tasks such as image tagging or road traffic monitoring. As another example, reCAPTCHA [29] exploits CAPTCHAs [22] (Completely Automated Public Turing test to tell Computers and Humans Apart), as a security measure to avoid web access to programs, in order to recognize words from scanned books that are challenging for OCR (Optical Character Recognition) systems. According to [10], “The practice of crowdsourcing is transforming the Web and giving rise to a new field”. Particularly relevant for our work with Vanet-X are those proposals that achieve the crowdsourcing results through the use of a videogame. A notable example is the ESP game [27], where players implicitly help to label images while playing the game. The use of videogames as learning tools is a clear example of the benefits of using educative videogames; as an example, CodeSpells [11] is a fantasy videogame where players have to write spells in Java. Other games with a hidden purpose exist, as commented in [28]. The multiplayer online game Planet PI4 [16] intends to serve as a testbed environment for Peer-to-Peer (P2P) game architectures. It is also interesting to mention that the term gamification has appeared to denote a variety of software that is inspired somehow by videogames [8, 9]. There exist some driving videogames that, as Vanet-X, are based on the use of real road maps or city layouts, such as Mini Maps (https://apps.facebook.com/minimaps/) and Push-Cars 2: On Europe Streets (http://www.push-cars. com). However, unlike in Vanet-X, in these games the players do not contribute to any crowdsourcing task or data management strategy evaluation. Finally, a good number of simulators of vehicular networks and mobility generators have been developed, such as TraNS [21], SUMO [19], Veins (Vehicles in Network Simulation) [25], GrooveNet [17], or VanetMobiSim [13]. Some interesting surveys can be found in [12, 18]. As commented along the paper, we argue that the videogame-based approach can be an interesting complement (but not a replacement) to the use of existing simulators to evaluate information management strategies for vehicular networks. Besides, mobility generators and vehicle simulators could potentially be used to generate neutral traffic for Vanet-X. 7. CONCLUSIONS AND FUTURE WORK We have developed a videogame that can be used to evaluate data management strategies for vehicular networks, as a complement to existing simulators. Whereas the opportunity of crowdsourcing through a videogame is attractive, several challenges arise. Thus, the goal of developing a fun videogame required the introduction of several elements that would not appear in a real scenario (like enemy cars), which could have an impact on the results, but on the other hand this will attract people to play. Moreover, the results obtained can depend not only on the benefits offered by the data management strategy but also on the ability of the specific player. So, whereas the videogame can provide an ideal tool to collect many data for a variety of scenarios, the experimental results obtained have to be judged with caution (e.g., we label the collected data with the skill level of the player). Even with these limitations, we argue that the videogame helps to collect with less effort data that can be used to fine-tune a protocol and/or obtain some initial conclusions, prior to the evaluation in more realistic scenarios. Additional information regarding the videogame is available at http://sid.cps.unizar.es/Vanet-X/, including a playable version of the videogame, some videos, and screenshots. This is a first step that shows the potential interest of exploiting videogames to evaluate data management strategies for vehicular networks. As future work, we would like to optimize and improve the videogame, as well as to develop a complete methodology and architecture to collect the data, evaluating the interest of the results obtained in other scenarios and in a larger scale. 8. ACKNOWLEDGMENTS This research work is currently supported by the CICYT project TIN2010-21387-C02-02 and DGA-FSE. The data management strategy adapted and used as an example in the videogame has been proposed in the context of the VESPA project, and we would like to warmly acknowledge the collaboration with Dr. Thierry Delot in that project. 9. REFERENCES [1] J. J. Blum, A. Eskandarian, and L. J. Hoffman. Challenges of intervehicle ad hoc networks. IEEE Transactions on Intelligent Transportation Systems, 5(4):347–351, 2004. [2] N. Cenerario, T. Delot, and S. Ilarri. A content-based dissemination protocol for VANETs: Exploiting the encounter probability. IEEE Transactions on Intelligent Transportation Systems, 12(3):771–782, 2011. [3] T. Delot, N. Cenerario, and S. Ilarri. Vehicular event sharing with a mobile peer-to-peer architecture. Transportation Research Part C: Emerging Technologies, 18(4):584–598, 2010. [4] T. Delot and S. Ilarri. Data gathering in vehicular networks: The VESPA experience (invited paper). In Fifth IEEE Workshop On User MObility and VEhicular Networks (LCN ON-MOVE 2011), pages 801–808. IEEE Computer Society, 2011. [5] T. Delot and S. Ilarri. Introduction to the Special Issue on Data Management in Vehicular Networks. Transportation Research Part C: Emerging Technologies, 23:1–2, 2012. 7 [6] T. Delot and S. Ilarri. The VESPA Project: Driving advances in data management for vehicular networks. ERCIM News, (94):17–18, July 2013. Special Theme on “Intelligent Vehicles as an Integral Part of Intelligent Transport Systems”. [7] T. Delot, S. Ilarri, S. Lecomte, and N. Cenerario. Sharing with caution: Managing parking spaces in vehicular networks. Mobile Information Systems, 9(1):69–98, 2013. [8] S. Deterding, D. Dixon, R. Khaled, and L. Nacke. From game design elements to gamefulness: Defining “gamification”. In 15th International Academic MindTrek Conference: Envisioning Future Media Environments (MindTrek’11), pages 9–15. ACM, 2011. [9] S. Deterding, M. Sicart, L. Nacke, K. O’Hara, and D. Dixon. Gamification: Using game-design elements in non-gaming contexts. In 2011 Annual Conference on Human factors in Computing Systems (CHI’11) – Extended Abstracts, pages 2425–2428. ACM, 2011. [10] A. Doan, R. Ramakrishnan, and A. Y. Halevy. Crowdsourcing systems on the World-Wide Web. Communications of the ACM, 54(4):86–96, 2011. [11] S. Esper, S. R. Foster, and W. G. Griswold. On the nature of fires and how to spark them when you’re not there. In 44th ACM Technical Symposium on Computer Science Education (SIGCSE’13), pages 305–310. ACM, 2013. [12] J. Harri, F. Filali, and C. Bonnet. Mobility models for vehicular ad hoc networks: A survey and taxonomy. IEEE Communications Surveys & Tutorials, 11(4):19–41, 2009. [13] J. H¨arri, F. Filali, C. Bonnet, and M. Fiore. VanetMobiSim: Generating realistic mobility patterns for VANETs. In Third International Workshop on Vehicular Ad Hoc Networks (VANET’06), pages 96–97. ACM, 2006. [14] H. Hartenstein and K. P. Laberteaux. A tutorial survey on vehicular ad hoc networks. IEEE Communications Magazine, 46(6):164–171, 2008. [15] G. Karagiannis, O. Altintas, E. Ekici, G. J. Heijenk, B. Jarupan, K. Lin, and T. Weil. Vehicular networking: A survey and tutorial on requirements, architectures, challenges, standards and solutions. IEEE Communications Surveys & Tutorials, 13(4):584–616, 2011. [16] M. Lehn, C. Leng, R. Rehner, T. Triebel, and A. Buchmann. An online gaming testbed for peer-to-peer architectures. ACM SIGCOMM Computer Communication Review, 41(4):474–475, 2011. [17] R. Mangharam, D. S. Weller, and R. Rajkumar. GrooveNet: A hybrid simulator for vehicle-to-vehicle networks. In Second International Workshop Vehicle-to-VehicleCommunications (V2VCOM’06), pages 1–8, 2006. [18] F. J. Martinez, C. K. Toh, J.-C. Cano, C. T. Calafate, and P. Manzoni. A survey and comparative study of simulators for vehicular ad hoc networks (VANETs). Wireless Communications & Mobile Computing, 11(7):813–828, 2011. [19] J. E. Michael Behrisch, Laura Bieker and D. Krajzewicz. SUMO – Simulation of Urban MObility: An overview. In The Third International Conference on Advances in System Simulation (SIMUL’11), pages 63–68. IARIA, 2011. [20] S. Olariu and M. C. Weigle, editors. Vehicular Networks: From Theory to Practice. Chapman & Hall/CRC, 2009. [21] M. Piorkowski, M. Raya, A. L. Lugo, P. Papadimitratos, M. Grossglauser, and J.-P. Hubaux. TraNS: Realistic joint traffic and network simulator for VANETs. SIGMOBILE Mobile Computing and Communications Review, 12(1):31–33, 2008. [22] C. Pope and K. Kaur. Is it human or computer? Defending e-commerce with Captchas. IT Professional, 7(2):43–49, 2005. [23] C. W. Reynolds. Steering behaviors for autonomous characters. In Game Developers Conference, pages 763–782. Miller Freeman Game Group, 1999. [24] M. L. Sichitiu and M. Kihl. Inter-vehicle communication systems: A survey. IEEE Communications Surveys & Tutorials, 10(1–4):88–105, 2008. [25] C. Sommer, R. German, and F. Dressler. Bidirectionally coupled network and road traffic simulation for improved IVC analysis. IEEE Transactions on Mobile Computing, 10(1):3–15, 2011. [26] Y. Toor, P. M¨uhlethaler, A. Laouiti, and A. de La Fortelle. Vehicle ad hoc networks: Applications and related technical issues. IEEE Communications Surveys & Tutorials, 10(1–4):74–88, 2008. [27] L. von Ahn and L. Dabbish. Labeling images with a computer game. In SIGCHI Conference on Human Factors in Computing Systems (CHI’04), pages 319–326. ACM, 2004. [28] L. von Ahn and L. Dabbish. Designing games with a purpose. Communications of the ACM, 51(8):58–67, 2008. [29] L. von Ahn, B. Maurer, C. McMillen, D. Abraham, and M. Blum. reCAPTCHA: Human-based character recognition via web security measures. Science, 321(5895):1465–1468, 2008. [30] T. L. Willke, P. Tientrakool, and N. F. Maxemchuk. A survey of inter-vehicle communication protocols and their applications. IEEE Communications Surveys & Tutorials, 11(2):3–20, 2009. [31] B. Xu, A. M. Ouksel, and O. Wolfson. Opportunistic resource exchange in inter-vehicle ad-hoc networks. In Fifth IEEE International Conference on Mobile Data Management (MDM’04), pages 4–12. IEEE Computer Society, 2004. [32] T. Yan, M. Marzilli, R. Holmes, D. Ganesan, and M. Corner. mCrowd: A platform for mobile crowdsourcing. In Seventh ACM Conference on Embedded Networked Sensor Systems (SenSys’09), pages 347–348. ACM, 2009. [33] M.-C. Yuen, I. King, and K.-S. Leung. A survey of crowdsourcing systems. In Third International Conference on Privacy, Security, Risk and Trust (PASSAT 2011) and Third International Conference on Social Computing (SocialCom 2011), pages 766–773. IEEE, 2011. 8 Anexo F Manual de usuario 245 1.2.1. Linux / Mac OS X Usando el script shell Se debe extraer el chero comprimido y ejecutar el script shell compilar.sh desde el interior de la carpeta extraída. \$> sh compilar.sh Nota: se crea un certicado para rmar el chero JAR (si no se había creado previamente), para lo cual es necesario seguir las instrucciones en pantalla. Para ello se crea un chero de almacenamiento de claves keystore, situado en la carpeta desde la que se ejecuta el comando. Usando Ant Se debe extraer el chero comprimido y ejecutar Ant desde el interior de la carpeta extraída. \$> ant Nota: se crea de forma transparente al usuario un certicado para rmar el chero JAR. 1.2.2. Windows Usando Ant Se debe extraer el chero comprimido y ejecutar Ant desde el interior de la carpeta extraída. \$> ant Nota: se crea de forma transparente al usuario un certicado para rmar el chero JAR. Nota: Para instalar ant , se debe descargarlo (por ejemplo de http://ant. apache.org/bindownload.cgi ), extraer el chero zip en algún lugar y añadir a la variable del sistema PATH el directorio bin obtenido de la extracción. De esta forma se habilita el uso del comando ant para usarlo desde la línea de comandos. 1.3. Ejecución El proceso requerido para la ejecución diere dependiendo del sistema operativo usado. 2 1.3.1. Linux / Mac OS X Una vez se haya completado la compilación, se debe ejecutar el script shell ejecutar_jar.sh para ejecutar el juego como una aplicación de escritorio Java \$> sh ejecutar_jar.sh o ejecutar el script shell ejecutar_applet.sh para ejecutarlo como un applet usando la aplicación appletviewer . \$> sh ejecutar_applet.sh 1.3.2. Windows Una vez se haya completado la compilación, se debe ejecutar el chero llamado RallyX3.jar , creado en el directorio dist \$> dist\RallyX3.jar 1.4. Finalización de la aplicación Para nalizar la aplicación, únicamente se necesita pulsar sobre el botón X (Cerrar) de la ventana de la aplicación. 2. Menús del juego En esta sección se explicarán las funciones realizadas por las diferentes pantallas del menú. En la gura 1 se puede observar cómo están distribuidas estas pantallas. Menú principal Crear una nueva partida Unirte a una partida existente (en red) Configuración de las reglas del juego Configuración del sistema VESPA Configuración avanzada de red Configuración avanzada de mapas Configuración avanzada de red (en unión) Opciones Ajustes de los controles Figura 1: Diagrama de navegación menús 3 2.1. Menú principal En el menú principal, se puede escoger entre Start a new game (crear una nueva partida), lo cual nos dirige a congurar y posteriormente comenzar una nueva partida, bien sea de un solo jugador o multijugador en red, o Join an existing game (unirse a una partida existente), lo cual nos permite unirnos a una partida en red en curso. También se puede modicar diversas opciones (como el volumen, los controles o el directorio de juego) pulsando sobre Options (opciones). Pulsando en el botón Credits (créditos) se accede a una pantalla en la que se muestra información sobre el autor, una breve introducción a VESPA y los agradecimientos. 4 2.2. Crear una nueva partida En la sección Start new game (crear una nueva partida), se debe seleccionar el apodo que se mostrará a los demás jugadores, el mapa en el que se desea jugar y el modo de juego deseado. Además, también se puede ver la dirección IP del computador (tanto la IP pública como la privada) en el campo de texto junto al botón view IP (ver IP). Pulsando sobre este botón se alterna entre mostrar un tipo u otro de dirección IP. El resto de jugadores que deseen unirse a la partida necesitarán conocer la dirección IP pública, por lo que es importante anotarla o recordarla. En esta pantalla de menú existen cuatro botones de conguración. El primero, VESPA conguration (conguración de VESPA), permite cambiar constantes, valores y modos relacionados con VESPA, así como también establecer el porcentaje de vehículos del tráco equipados con el sistema VESPA. El segundo, Advanced network conguration (conguración avanzada de red), permite cambiar el puerto en el cual el servidor escuchará a la espera de peticiones de conexión de nuevos jugadores, así como también el puerto que usará nuestro cliente para conectarse. Es importante asegurarse de abrir en el NAT/rewall los puertos seleccionados tanto en TCP como UDP. En esta pantalla también aparece un desplegable en el cual se debe seleccionar la dirección IP correspondiente al adaptador de red que deseamos usar para crear la partida. 5 El tercero, Advanced map conguration (conguración avanzada de mapas), nos dirige a una nueva pantalla en la cual se podrá añadir, eliminar y previsualizar los mapas. El último, Game rules conguration (conguración de las reglas del juego), permite cambiar algunas opciones como la dicultad, el número de equipos y el número de vehículos neutrales (del tráco). Cuando se hayan establecido todas las opciones como se desea, se debe pulsar en el botón Start (comenzar) para comenzar la partida. Si por el contrario deseamos volver a la pantalla anterior, se debe pulsar en el botón Go back (volver). 2.3. Conguración de las reglas del juego En este menú, en la mitad izquierda, se puede personalizar la dicultad cambiando los factores separadamente. Se debe tener en cuenta que cuando el jugador asume el rol de perseguidor (modo de juego capture the red cars) el valor del daño se revierte. Ejemplo: Un valor bajo de daño del vehículo, en un modo de juego en el que el jugador huya de los vehículos controlados por el computador signica que el jugador tiene una resistencia mayor de la normal, mientras que en un modo de juego en el que el jugador sea el que persigue a los vehículos del computador signica que dichos vehículos tienen menos resistencia y por lo tanto es más fácil para el jugador cazarlos. En la mitad derecha de la pantalla, se puede cambiar el número del máximo de equipos, el número de vehículos neutrales (del tráco), el número de vehículos 6 enemigos y el número de rondas establecido como límite en los modos de juego competitivos. Debajo, se puede congurar el tiempo límite de los diferentes modos de juego así como también el tiempo de espera entre rondas. 2.4. Conguración del sistema VESPA En este menú es posible congurar una gran variedad de parámetros relacionados con el funcionamiento del protocolo VESPA. En la pantalla inicial se encuentra una muy breve descripción del sistema VESPA y sus ventajas (accesible manteniendo el puntero encima del símbolo de información), también un selector del porcentaje de vehículos del tráco que se desea que estén equipados con el protocolo VESPA y una casilla de vericación que en el caso de estar activada indica que la generación de eventos avisando de enemigos y otros jugadores se realizará mediante observación en lugar de autogeneración desde los propios vehículos. Por último existe otra casilla de vericación Expert conguration (conguración experta) que de activarse despliega más aspectos congurables del protocolo. 7 Las opciones que se pueden congurar son las siguientes: Alcance de la radio (Radio range) y alcance de visión (Sight range), que indican la distancia a la que se pueden transmitir y observar los eventos respectivamente. Intervalo de actualización (Update interval) del sensor (Sensor), del gestor de almacenamiento (Storage Manager) y del procesador de consultas continuo (Continuous Query Processor), que indica cada cuántos segundos entrarán en funcionamiento dichos módulos. Importancias de los distintos tipos de eventos (Event type importance), que indica la importancia que se dará a un evento de dicho tipo, de forma que cuanto mayor sea mayor será la posibilidad de que se muestre al conductor. Además, pulsando sobre la echa amarilla Mega-expert cong se accede a una segunda página con más elementos para congurar. 8 En esta segunda página de conguración se permite modicar más parámetros de VESPA. Dichos parámetros solo deberían ser modicados por una persona con unos mínimos conocimientos del protocolo ya que mediante su modicación se puede alterar gravemente el comportamiento del sistema. 2.5. Conguración avanzada de red En esta pantalla de menú existen dos campos de texto y un desplegable. En el campo de texto superior, se puede modicar el puerto que se usará para 9 conectar con el servidor que se cree (esto es necesario ya que la aplicación está internamente separada en un servidor y un cliente, incluso para el caso de jugar un único jugador). En el segundo campo de texto, se puede modicar el puerto en el que la aplicación escuchará las peticiones de unión de los jugadores que deseen unirse a la partida. En el desplegable aparecen las direcciones IP asociadas con cada adaptador de red habilitado, debiéndose elegir la que corresponde al adaptador que nos permite comunicarnos con la red en la que se hayan el resto de jugadores. Nota: es importante comprobar que los puertos seleccionados están abiertos en el NAT/rewall en los modos TCP y UDP. 2.6. Conguración avanzada de mapas En esta pantalla de menú, en la que se pueden descargar nuevos mapas que se quedarán almacenados en el directorio de juego para futuras partidas, existen dos secciones diferenciadas. La mitad derecha, en la cual se puede buscar una dirección, previsualizar el área resultante y nalmente añadirla como nuevo mapa, y la mitad izquierda, donde hay una tabla que contiene los mapas agregados y en la cual podemos previsualizar o eliminar dichos mapas. 10 Añadir un nuevo mapa al juego es un proceso muy sencillo. Todo lo que se necesita es escribir la dirección deseada en el campo de texto Address keywords (palabras clave de la dirección) y pulsar en el botón Search (buscar). Esto realiza una búsqueda a través del servicio Nominatim de OpenStreetMap . Si hay resultados, éstos aparecerán en el desplegable Search results (resultados de la búsqueda). Posteriormente, se debe seleccionar el tamaño deseado del mapa (usando el control deslizante Map size (tamaño del mapa). En el campo de texto Alias se debe escribir un alias representativo para poder reconocer el mapa desde el desplegable de selección de mapa del menú de creación de la partida. Si se desea, es posible previsualizar el área entorno a la dirección seleccionada pulsando el botón View map (ver mapa). Finalmente, se debe pulsar el botón Add map (añadir mapa) con el n de añadir dicho mapa al juego. Consejo : los resultados devueltos por la búsqueda de una dirección están limitados en número. Por este motivo, si se desea buscar una dirección con muchos posibles resultados, y no se obtienen los resultados deseados, debe procurar suministrarse una descripción más precisa de la dirección. Consejo : cuanto más pequeño sea el tamaño del mapa mejor rendimiento del juego se obtendrá. Además, los mapas con muchos detalles pueden no ser capaces de ejecutarse en tamaños grandes o incluso medianos. 11 3. El juego En esta sección se mostrarán todos aquellos aspectos necesarios de conocer para poder participar en las partidas, como son los diferentes modos de juego, elementos de la partida (tipos de vehículos, tipos de terreno, etc.), controles del jugador y funcionalidades del menú de in-game. 3.1. Modos de juego Se han desarrollado cinco modos de juego diferentes: Capture the ag , Capture the red cars , Solve the tasks , Task endurance survival y Special parking mode . Excepto el último, que solo está disponible en modo competitivo, los demás pueden ser jugados tanto en modo cooperativo como competitivo. A excepción del cuarto modo, los demás funcionan mediante un sistema de rondas. Cuando comienza una ronda, se tiene unos pocos segundos para conducir libremente antes de que aparezcan los objetivos y los perseguidores. Pero aún sin enemigos hay que tener cuidado, ½las colisiones con otros vehículos también producen daños!. Después de este tiempo de preparación, la ronda empieza y se muestra una cuenta atrás con el tiempo disponible para completar los objetivos. Cuando éstos hayan sido completados, los vehículos enemigos (si los había) desaparecerán, se rellenará la salud del jugador y la ronda nalizará. Jugando en modo cooperativo las rondas son innitas, se juega hasta que todos los jugadores mueran, pero en el modo cooperativo las rondas están limitadas por un valor que se puede modicar en el menú Game rules conguration (conguración de las reglas del juego). Nota : para repostar en una gasolinera es preciso que el vehículo esté completamente detenido. 3.1.1. Capture the ag En este modo de juego se deben capturar todas las banderas (normalmente cinco) mientras se huye de los vehículos enemigos que intentan destruirnos. Hay que tener cuidado ya que se recibe un poco de daño en las colisiones contra los vehículos del tráco, y mucho daño colisionando con los enemigos, los cuales tienen vida innita. 18 3.1.2. Capture the red cars En este modo de juego se deben capturar todos los vehículos enemigos, los cuales tratan de escapar del jugador. El jugador únicamente recibe daño colisionando con vehículos del tráco, mientras que los vehículos enemigos solo reciben daño con las colisiones con el jugador (no reciben daño colisionando contra otros vehículos). 3.1.3. Solve the tasks En este modo de juego se deben completar diversas tareas antes de que el tiempo se agote o los vehículos enemigos destruyan al jugador. Existen diferentes tipos de tareas: Conducir hasta una dirección o sitio de interés Aparcar en una plaza cercana a una dirección o sitio de interés (por cercana se entiende que sea una de las tres más próximas al objetivo). Llegar a pie a una dirección o sitio de interés, para lo cual previamente se ha tenido que aparcar el vehículo y así poder salir de él. Nota : en las tareas que requieran llegar al objetivo a pie, es recomendable aparcar lo más cerca posible ya que el jugador es más lento y vulnerable mientras va a pie por lo que es una presa fácil para los vehículos enemigos. 3.1.4. Task endurance survival Este modo de juego tiene una mecánica totalmente diferente del resto de modos de juego. Los otros modos usan un sistema estricto de rondas -en los cuales si una ronda es completada satisfactoriamente los enemigos desaparecen y el jugador avanza a la siguiente ronda, y en caso contrario se pierde la partida-, sin embargo, es este modo de juego, los enemigos no desaparecen entre rondas ni tampoco se pierde la partida si no completas los objetivos de la ronda, sino que simplemente se pierde la oportunidad de ganar la recompensa de dicha ronda. La partida se acaba cuando todos los equipos tienen una cantidad negativa de dinero (que sustituye a los puntos en este modo de juego), hasta ese momento todos los jugadores que sigan vivos podrán seguir jugando. 19 Si una ronda es completada satisfactoriamente, todos los jugadores todavía vivos recuperan un 50% de vida y los muertos recuperan el 100%. En ambos casos dichos jugadores perderán dinero, pero recuperar vida es más caro si el jugador está muerto que si solamente dañado. En cada ronda, el jugador debe completar una tarea, que puede ser lograda conduciendo, andando o aparcando en uno de los tres aparcamientos más cercanos (según se indique en la tarea), y la cual puede consistir en acudir a una dirección o a un sitio de interés de un determinado tipo (p.ej. ir a una farmacia). 3.1.5. Parking special mode Este modo de juego, creado expresamente para facilitar la toma de estadísticas de aparcamiento, consiste en completar una serie de tareas de aparcamiento mediante un sistema de rondas, de forma muy similar al modo Solve the task. Las diferencias con ese modo radican en que en cada ronda hay un doble objetivo, que se debe cumplir de forma secuencial, en el que primero se requiere acudir a un determinado punto dado por una dirección o sitio de interés, y a continuación se requiere encontrar un aparcamiento situado a menos de 500m. 3.2. Controles Los controles del juego son muy sencillos, ya que únicamente es preciso usar las echas de dirección, la barra espaciadora y la tecla control. Las echas de dirección se usan para controlar el movimiento del vehículo: La echa superior ( ↑ ) acelera. La echa inferior ( ↓ ) frena y da marcha atrás. La echa izquierda ( ← ) gira a la izquierda (rota el coche en sentido contrario a las agujas del reloj). La echa derecha ( → ) gira a la derecha (rota el coche en el sentido de las agujas del reloj). 20 La barra espaciadora se usa para crear una nube de humo. La tecla Control es usada para aparcar y salir o entrar del vehículo. La tecla Escape permite desplegar el menú in-game en el cual se pueden visualizar los controles, modicar el volumen y abandonar la partida. 3.3. Elementos Durante las partidas el jugador encontrará diferentes tipos de vehículos, terrenos y objetivos. A continuación se explicarán los más relevantes de estos elementos del juego. 3.3.1. Vehículos Hay varios tipos diferentes de vehículos: Jugadores : reconocibles por ser azules (con una banda central de color en el caso de necesitar diferenciar los diferentes equipos). Son los vehículos controlados por los jugadores. Vehículos enemigos : reconocibles por ser rojos. Son los coches controlados por el computador que, dependiendo del modo de juego, tratan de cazar al jugador o huir de él. También es posible reconocerlos por el sonido del motor que se puede escuchar cuando se acercan. 21 Ambulancias : reconocibles por su forma y por su luz estroboscópica roja y azul. Además es posible escuchar su sirena cuando se acerca. Controladas por el computador. Aparece de forma aleatoria y desaparece cuando ha transcurrido un tiempo mínimo y no está a la vista de ningún jugador. Puede haber una única ambulancia sobre el escenario, siendo avisados los jugadores de su aparición y desaparición. Vehículos del tráco : el resto de vehículos que no coinciden con las descripciones anteriores. Controlados por el computador. 3.3.2. Terrenos Existen diferentes tipos de terrenos, algunos de los cuales son infranqueables para los vehículos: Calzada pavimentada : de color gris oscuro, es el terreno por el que circulan los vehículos del tráco. Calle peatonal : de color blanco, solo los vehículos de los jugadores y los enemigos pueden circular en ella, sufriendo además una ralentización a la marcha. Agua : de color azul, es infranqueable. Carril bici : de color verde con línea de separación discontinua, únicamente los vehículos de los jugadores pueden circular por él, sufriendo una ralentización a la marcha. Obras : de color marrón, únicamente los vehículos de lo jugadores y los vehículos enemigos pueden atravesarlas, viéndose ralentizados. Playa y césped : de color marrón claro y verde respectivamente, solamente los vehículos de los jugadores y los enemigos pueden circular por ellos, sufriendo además una ralentización a la marcha. Zonas urbanizadas y edicios : son áreas de color gris claro y marrón bordeado en negro respectivamente, que son infranqueables para cualquier tipo de vehículo. 22 Nota : cuando el jugador circula a pie se le aplican las mismas reglas que si lo hiciera a bordo del vehículo. 3.3.3. Objetos y lugares de interés Hay algunos objetos y lugares importantes que deben ser reconocidos ya que pueden ser utilizados como objetivo de la ronda según el modo de juego elegido. Banderas : Una bandera que debe ser tomada para lograr puntos y rellenar las nubes de humo. Gasolineras : Un lugar donde se puede repostar combustible. Sitios de interés : lugares como: • cafés • restaurantes de comida rápida • bancos • farmacias • escuelas • tiendas 23 • hostales • moteles • hoteles • museos Son reconocibles por estar marcados con un círculo verde con el nombre pintado en letras rojas. Plazas de aparcamiento : son los lugares en los cuales, según el modo de juego, el jugador puede abandonar el vehículo para continuar a pie. También son los objetivos de diversos modos de juego. Para realizar un aparcamiento, el jugador debe aproximarse a una plaza vacía y una vez en su interior (cuando las líneas discontinuas cambien a color rojo) pulsar la tecla Control. Para abandonar el aparcamiento el procedimiento es el mismo. 24 Nota : es importante tener en cuenta que el tiempo que una plaza permanece ocupada por un vehículo del tráco varía (por defecto es entre 20 y 40 segundos), pero algunas plazas nunca se llegarán a desocupar. 3.3.4. Otros Nube de humo : se trata de un elemento temporal creado por los jugadores que, cuando es colisionada por un vehículo, le causa una reducción temporal de la velocidad así como una pérdida del control de la dirección del vehículo. Permanece únicamente durante diez segundos desde que es creada. 25 3.4. Interfaz gráca de usuario La interfaz gráca de usuario muestra información útil durante la partida. La información que contiene es la siguiente: 1) Puntuación : muestra la cantidad de puntos logrados hasta el momento. 2) Indicador de salud : muestra la cantidad de daño recibido por el vehículo. Su color varía de forma gradual desde el verde hasta el rojo según se reciban más daños. 3) Nubes de humo disponibles : muestra cuantas nubes de humo quedan disponibles. La cantidad máxima es cinco. 4) Cuenta atrás : muestra cuanto tiempo queda para lograr los objetivos de la ronda. 5) Localización actual : muestra el nombre de la calle en la que se encuentra el jugador. En el caso de estar situado sobre una intersección, se muestra el nombre de todas las calles de dicha intersección. 6) Indicador de gasolina : muestra de forma gráca la cantidad de combustible restante. 26 7) Radar : muestra un mini-mapa en el que se representan los eventos VESPA y los lugares de interés. 8) Indicador de FPS : muestra el rendimiento actual de la aplicación medido en fotogramas por segundo. 9) Flechas : son echas de colores que muestran en qué dirección respecto del jugador se encuentran los objetivos y los perseguidores (si los hay). Las echas rojas indican la presencia de un perseguidor, mientras que las verdes indican los objetivos. El radar muestra de forma gráca los eventos considerados relevantes en el sistema VESPA, junto con otros lugares considerados de interés para la consecución de los objetivos de la ronda. Cada icono representa un evento (salvo los que representan un icono siempre visible). Se pueden mostrar diferentes iconos reriéndose al mismo incidente, ya que varios vehículos han podido detectarlo. Por lo tanto, no se recibirá un único icono en el punto donde el incidente ha tenido lugar, sino varios iconos en torno a dicho lugar. Estos son los iconos siempre visibles : : nuestro jugador. : gasolinera. 27 argumentos la dirección IP y el puerto en el que se ubica el servidor dedicado con el que se desea conectar (p.ej. java -jar RallyX3.jar -terminal 192.168.1. 161 5550 ). Si existe un servidor dedicado en funcionamiento en dicha ubicación se requerirá introducir la contraseña establecida para dicho servidor. Si no existe el servidor o la contraseña es incorrecta, el proceso nalizará. Si la contraseña es correcta, aparecerá el menú con las siguientes opciones: modicar conguración del juego: modica todas las opciones del juego que se conguran desde las pantallas de los menús, excepto las relativas a VESPA. modicar ParamCong.txt : modica los valores de dicho chero. modicar conguración de VESPA: modica la conguración del sistema VESPA. modicar mapa: se solicita la elección de un nuevo mapa para la partida. recuperar los cheros estadísticos creados: crea en el directorio que se desee una copia de todos los cheros de estadísticas existentes en el directorio de juego del servidor dedicado, dando la opción de borrar los originales al nalizar. 34 salir: naliza el proceso. 4.3. Creación del servidor de recogida de estadísticas Para la creación de una instancia del servidor de recogida de estadísticas debe ejecutarse el juego con el siguiente comando: java -jar RallyX3.jar -statserver . 35 Nada más iniciarse, el proceso actualiza la dirección IP a la que apunta la DDNS (DNS dinámica) nrxss.twilightparadox.com , que es con la que conectan los servidores. Acto seguido, se requiere seleccionar el directorio donde se escribirán las estadísticas que se reciban, después de lo cual el proceso permanecerá a la espera de conexiones de los servidores. 5. Conguración técnica avanzada Existen diversos parámetros del juego que pueden ser modicados de forma externa a los menús de la aplicación. Estos parámetros modican aspectos clave en el funcionamiento del juego por lo que debe tomarse especial precaución en su modicación. 5.1. Modicación de los APIs usados para la obtención de los mapas En el directorio de juego, en el interior de la carpeta Maps, se encuentra un chero OSM_APIs.txt que contiene un listado de URLs apuntando a diferentes APIs de OpenStreetMap que pueden ser usadas. El juego, cuando trate de añadir un nuevo mapa, probará primero con la primera API de la lista y si ésta devuelve un mensaje de error se probará con la siguiente, y así sucesivamente. Si se llega al nal de la lista sin lograr descargar el mapa, se hará uso de la API ocial, cuya URL se contiene dentro del código del juego. 36 5.2. Modicación del chero de conguración ParamCon- g.txt En el directorio de juego se encuentra el chero de texto ParamCong.txt, que contiene diversos parámetros del juego que pueden ser modicados por el usuario. El chero está estructurado de forma que por cada parámetro existe una primera línea con el nombre (que comienza por el carácter #) seguida de otra línea con el valor que toma. La lista de los parámetros incluidos y sus descripciones es la siguiente: Nombre Valor por defecto Descripción radioMaxMapa 0.0050 Radio máximo del selector de tamaño al añadir un nuevo mapa. En unidades UTM. radioPeqMapa 0.0030 Radio mínimo del selector de tamaño al añadir un nuevo mapa. En unidades UTM. MaxBytesUDP 6000 Tamaño máximo de los mensajes de red (en bytes) MaxExtrapolation 5 Número máximo de ciclos sobre los que se podrá aplicar la técnica de extrapolación cuando sea necesaria. MaxInterpolation 2 Número de ciclos sobre los que se aplicará la técnica de interpolación. Aumentar este valor reducirá los saltos de posición del resto de vehículos a costa de aumentar la latencia del jugador. NUM_PARKINGS_FIJOS 30 Número de plazas de aparcamiento falsas (están permanentemente ocupadas). NUM_PARKINGS 10 Número de plazas de aparcamiento útiles (se ocupan y desocupan a lo largo de la partida). NUM_FX 20 Número máximo de efectos visuales simultáneos (humos, mareos, etc.). 37 timeoutWaitingPlayers 60 Tiempo que puede estar el servidor esperando a que se conecte el primer jugador antes de abortar la creación de la partida. timeoutWaitingPlayersDedicated 180 Tiempo que puede estar el servidor dedicado esperando a que se conecte el primer jugador antes de abortar la creación de la partida. framesPropagacionExplosion 5 Número de ciclos en los que se envía el aviso de que ha habido una explosión al cliente. Este valor debe aumentarse en caso de altas latencias, ya que de lo contrario no se visualizarán las explosiones. maxTC 50 Valor máximo para el campo Number of neutral cars de la pantalla Game rules conguration. maxRC 8 Valor máximo para el campo Maximum number of enemy cars de la pantalla Game rules conguration. maxNodos 10000 Número máximo de nodos de un mapa. No se permitirá descargar mapas con un número de nodos mayor a este valor. WOLFSON (ON=1) 0 Aplicación del método WOLFSON en la implementación de VESPA. maxPlayers 8 Número máximo de jugadores que se puedan unir a una partida. cochesBuscandoParking 10 Vehículos del tráco que están buscando aparcamiento (número constante en el tiempo). TIEMPO_CAMBIO 20000 Tiempo mínimo que permanecerá un vehículo del tráco aparcado. En milisegundos. MARGEN_TIEMPO_CAMBIO 20000 Tiempo máximo (adicional sobre el mínimo) que permanecerá un vehículo del tráco aparcado. En milisegundos. 38 RADIO_PARKING_VALIDO 500 Distancia máxima a la que se considera que un aparcamiento está cercano a un objetivo. En metros. PARKING_PROTOCOL (0=Time,1=Distance,2=EP,3=None) 2 Tipo de protocolo de reserva (de aparcamiento) usado en la implementación de VESPA. DISTANCIA_CERCA 700 Distancia máxima respecto del jugador a la que se recibirán datos del resto de elementos. Se debe aumentar si se quiere tener conocimiento de la posición del resto de vehículos en el radar cuando la opción #debugRadar (ON=1) está activada. debugRadar (ON=1) 0 Muestra en el radar el resto de vehículos y las plazas de aparcamiento y su ocupación. VESPA_StatisticsOn (ON=1) 1 Activa la recogida de datos estadísticos de VESPA. Parking_Player_StatisticsOn (ON=1) 1 Activa la recogida de datos estadísticos de aparcamientos de jugadores. Parking_Trac_StatisticsOn (ON=1) 1 Activa la recogida de datos estadísticos de aparcamientos de vehículos del tráco. Game_StatisticsOn (ON=1) 1 Activa la recogida de datos estadísticos del resumen de la partida. Stat server IP nrxss.twilightparadox.com URL o dirección IP de la ubicación del servidor estadístico al que se desea enviar las estadísticas recogidas. Stat server port 5558 Puerto en el que escucha el servidor estadístico al que se desea enviar las estadísticas recogidas. Cambio VESPA y protocolo aparcamiento automatico (0=desactivado) 0 Cambio automático entre diferentes implementaciones de VESPA ( VESPA+P , VESPA-P y sin VESPA ). Se debe indicar cada cuantas rondas se desea que se realice el cambio. Allow untrained players ignoring statistics (ON=1) 0 Permite que jugadores sin habilidad suciente se unan a partidas del modo de juego Parking special mode. 39 Minimum skill level to qualify a player as trained 0.0083 Habilidad mínima exigida para que un jugador pueda unirse a partidas del modo de juego Parking special mode. Disable in-game transparencies (disable=1) 0 Deshabilita las transparencias prescindibles en los grácos del juego. Disable prediction of collisions (disable=1) 0 Deshabilita la predicción de las colisiones en el cliente (aumenta el rendimiento a costa de mayores errores de predicción) Data management strategy selected vespa Implementación de Data Management Strategy deseada. Nota : la modicación de los valores por defecto puede hacer el juego injugable o perjudicar su rendimiento. Nota : Para volver a usar los valores por defecto se debe eliminar este archivo. Al volver a iniciar el juego el archivo se creará de nuevo con los valores iniciales. 6. Resolución de problemas A continuación se describen los problemas más comunes y sus posibles soluciones. 6.1. Bajo rendimiento (framerate bajo) Posibles causas: elección de un mapa demasiado extenso o detallado: debe prestarse atención al número de nodos que posee el mapa y descargar el mismo mapa con un menor tamaño. demasiados vehículos: debe probarse a reducir el número de vehículos del tráco y de vehículos enemigos. problema con el pintado de transparencias: se puede comprobar pulsando la tecla Q durante el juego para desplegar la información de ronda, que es transparente, y observar si en ese momento el framerate disminuye drásticamente. En caso armativo debe deshabilitarse el pintado de transparencias mediante el parámetro #Disable in-game transparencies (disable=1) del chero ParamCong.txt (ver apartado 5.2). 40 6.2. Error de conexión en los primeros segundos de la partida Debe asegurarse que los valores de los parámetros #DISTANCIA_CERCA y #debug Radar (ON=1) del chero ParamCong.txt coincida en todos los clientes y el servidor. 6.3. Corrupción u obsolescencia de los datos El formato de los cheros ParamCong.txt, cong y data puede variar en diferentes versiones del juego. Cuando se actualice a una nueva versión, si no se proporciona ninguna herramienta para realizar la conversión, deben eliminarse dichos cheros para que el juego cree las versiones por defecto al iniciarse. 7. Licencias Developing Games In Java Algunos de los algoritmos descritos en el libro han sido usados en esta aplicación. Copyright (c) 2003, David Brackeen All rights reserved. Redistribution and use in source and binary forms, with or without modi- cation, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of David Brackeen nor the names of its contributors may be used to endorse or promote products derived from this software without specic prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS " AS IS " AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 41 OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. JLayer Available at http://www.javazoom.net/javalayer/javalayer.html . This program is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. OpenSteer Algunos de los algoritmos y estructuras de datos de esta librería han sido adaptados para el uso en esta aplicación. Available at http://opensteer.sourceforge.net/ . OpenSteer is distributed as open source software in accordance with the MIT License. For more information see http://opensource.org/licenses/mitlicense.php Xerces Available at http://xerces.apache.org/#xerces2-j . This component is licensed under Apache License Version 2.0. For more information see http://www.apache.org/licenses/LICENSE-2.0 . Guava (Google Core Libraries for Java) Available at https://code.google.com/p/guava-libraries/ . This component is licensed under Apache License Version 2.0. For more information see http://www.apache.org/licenses/LICENSE-2.0 . Música : - Methylchloroisothiazolinone (Instrumental Version) album Dirty Wings (Instrumental Version) by Josh Woodward (Instrumental Versions) . Available under a Creative Commons Attribution 3.0 Unported licence. 42 For more information see http://creativecommons.org/licenses/ by/3.0/ . Available at http://www.jamendo.com/es/track/760400/ methylchloroisothiazolinone-instrumental-version - Video game album Metamorphosis by Howarang Van K . Available under a Creative Commons Attribution-ShareAlike 3.0 Unported licence. For more information see http://creativecommons.org/licenses/ by-sa/3.0/ . Available at http://www.jamendo.com/es/track/923426/ video-game 43