1
Download VIDEOJUEGO DE ESTRATEGIA PARA NAVEGADORES WEB EN
Document related concepts
Transcript
UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA VIDEOJUEGO DE ESTRATEGIA PARA NAVEGADORES WEB EN TIEMPO REAL: WARBATTLE AUTOR: HECTOR LOPEZ POMBO MADRID, SEPTIEMBRE 2009 Autorizada la entrega del proyecto del alumno: HECTOR LOPEZ POMBO El Director del Proyecto CRISTINA PUENTE AGUEDA Fdo.: ……………………….. Fecha: / / Vº Bº del Coordinador de Proyectos DAVID CONTRERAS BÁRCENA Fdo.: ……………………….. Fecha: / / UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA VIDEOJUEGO DE ESTRATEGIA PARA NAVEGADORES WEB EN TIEMPO REAL: WARBATTLE AUTOR: HECTOR LOPEZ POMBO DIRECTOR: CRISTINA PUENTE AGUEDA MADRID, SEPTIEMBRE 2009 A mis padres: “Por tener siempre confianza en mí y haberme ayudado en todos los momentos difíciles. Gracias por la oportunidad que me habéis dado con vuestro esfuerzo, jamás hubiese llegado hasta aquí de no ser por vosotros. Con que tan sólo estéis una pequeña parte orgullosos de mí como yo lo estoy de vosotros ya seré el hombre más feliz.” A mi abuela: “Carmen, el haber llegado hasta este punto de mi vida sé que te hubiese hecho la abuela más feliz del mundo como a mí me hiciste el nieto más afortunado. Ojala me veas estés donde estés. Siempre en mi corazón.” RESUMEN Hoy en día muchas personas viven con un estrés continuo debido al trabajo, las prisas y otras obligaciones. En este contexto cualquier entretenimiento con el que poder desconectar un poco de la rutina siempre es bienvenido. Por este motivo y por la aparición en las últimas décadas de un nuevo concepto de diversión, los videojuegos, este proyecto se unirá al grupo de títulos de este sector en continua expansión. El proyecto que se va a realizar se denomina WarBattle y consistirá en un videojuego en tiempo real pensado para jugar de forma gratuita y sin descargas mediante cualquier navegador de Internet como Internet Explorer, Mozilla Firefox, Safari, etc. El sistema creado abarcará todos los procesos de la ingeniería del software, desde la creación conceptual del entorno de juego hasta el desarrollo del producto software final. WarBattle va a ser un juego de estrategia ambientado en una época medievalfantástica, al más puro estilo de éxitos como Dungeons & Dragons. En él miles de jugadores competirán y colaborarán entre sí en función de sus gustos y necesidades para erigirse como los mejores estrategas del universo Warbattle. A diferencia de lo que puede sugerir el título, el juego está pensado para gente de casi cualquier edad, pudiendo variar entre los 12 y los 50 años el perfil del jugador. El motivo de que el rango sea tan variado es que WarBattle pretende ser un juego entretenido en el que se prioriza la estrategia a la acción. Por otro lado, no es un juego que requiera de una atención constante, la frecuencia de uso se amolda al estilo del jugador, delegando en éste la decisión de utilizar una estrategia u otra. ABSTRACT Nowadays, most people coexist with the so-called environmental stress caused by job, haste or duties. In this regard, any amusement to relieve the day-by-day obligations is always more than welcome. Due to this fact and to the advent of a new concept of entertainment as from last years, that is, the video games, this project joins the list of products corresponding to the software expanding commercial sector. The project carried out is named WarBattle and is developed as a real-time video game, completely free and without software’s downloads, driven through internet navigators such as Internet Explorer, Mozilla, Firefox, Safari, etc. The designed system covers all the engineering processes of software, from the conceptual creation of the game’s environment to the development of the final software product. WarBattle is a new strategic video game set in fantastic Middle Ages, following the path open by big hits such as Dungeons & Dragons. Therefore, thousands of players will compete and cooperate among them, on the basis of their needs or wishes, in order to become the best strategist in the WarBattle universe. In spite of its name, this video game is intended for people of all ages, ranging the players’ profile from 12 to 50 years-old. Such wide age scope is because of WarBattle prioritizes strategy instead of action. On another front, playing WarBattle does not require to pay attention to the game all the time, since players may freely adapt the game’s pace to their liking, as the strategic decisions are delegated to them. INDICE 1. Introducción ......................................................................................................................... 1 1.1 Introducción ................................................................................................................... 2 1.2 Objetivos ........................................................................................................................ 4 2. Estado del arte ..................................................................................................................... 5 2.1 Historia de los videojuegos ............................................................................................. 6 2.2 Los Browser Games......................................................................................................... 9 2.3 Metodología ................................................................................................................. 11 3. Análisis de requisitos .......................................................................................................... 13 3.1 Introducción ................................................................................................................. 14 3.2 Estudio de la ambientación ........................................................................................... 15 3.2.1 Elementos del juego .............................................................................................. 16 3.2.2 Restricciones ......................................................................................................... 49 3.3 Modelo de dominio ...................................................................................................... 51 3.3.1 Entorno del jugador a nivel global .......................................................................... 52 3.3.2 Entorno de las aldea .............................................................................................. 54 3.3.3 Sistema de producción........................................................................................... 56 3.3.4 Sistema de costes .................................................................................................. 58 3.3.5 Unidades militares ................................................................................................. 60 3.3.6 Unidades defensivas .............................................................................................. 62 3.3.7 Restricciones ......................................................................................................... 64 3.3.8 Misiones ................................................................................................................ 73 3.3.9 Elementos en construcción .................................................................................... 76 3.3.10 Sistema de coordenadas ...................................................................................... 84 3.4 Análisis de los casos de uso ........................................................................................... 86 3.4.1 Acceso al sistema ................................................................................................... 87 3.4.2 Acciones informativas ............................................................................................ 92 3.4.3 Acciones sobre la producción............................................................................... 103 3.4.4 Acciones sobre los edificios.................................................................................. 110 3.4.5 Acciones sobre unidades militares ....................................................................... 125 3.4.6 Acciones sobre unidades defensivas .................................................................... 132 3.4.7 Acciones sobre las ciencias .................................................................................. 139 3.4.8 Acciones sobre las habilidades militares .............................................................. 147 3.4.9 Acciones sobre el mapa ....................................................................................... 155 3.4.10 Acciones sobre misiones .................................................................................... 166 3.5 Problemas y errores .................................................................................................... 173 3.6 Conclusiones ............................................................................................................... 175 4. Diseño .............................................................................................................................. 177 4.1 Introducción ............................................................................................................... 178 4.2 Arquitectura lógica ..................................................................................................... 180 4.2.1 Dominio............................................................................................................... 182 4.2.2 Controlador ......................................................................................................... 183 4.2.3 Vista .................................................................................................................... 185 4.2.4 Motor .................................................................................................................. 186 4.2.5 DAO ..................................................................................................................... 188 4.3 Diseño de la base de datos .......................................................................................... 189 4.3.1 Tipos de elementos.............................................................................................. 191 4.3.2 Costes y producción ............................................................................................. 191 4.3.3 Elementos de los usuarios ................................................................................... 192 4.3.4 Elementos de las aldeas ....................................................................................... 192 4.3.5 Elementos de los productores y edificios ............................................................. 193 4.3.6 Elementos de las ciencias y habilidades militares ................................................. 193 4.3.7 Elementos de las unidades militares .................................................................... 194 4.3.8 Elementos de las unidades defensivas ................................................................. 194 4.3.9 Elementos de las misiones ................................................................................... 195 4.3.10 Elementos del mapa .......................................................................................... 195 4.4 Algoritmos significativos ............................................................................................. 196 4.4.1 Alta usuario ......................................................................................................... 197 4.4.2 Actualizar ............................................................................................................ 200 4.4.3 Construcción de unidades militares ..................................................................... 211 4.4.4 Alta misiones ....................................................................................................... 212 4.5 Problemas y errores .................................................................................................... 213 4.6 Conclusiones ............................................................................................................... 215 5. Trabajo futuro .................................................................................................................. 217 6. Evaluación económica ...................................................................................................... 221 7. Bibliografía ....................................................................................................................... 223 ANEXO A: Manual de usuario ............................................................................................... 225 WarBattle CAPÍTULO 1 Introducción 1 Introducción 1. En plena crisis mundial el sector de los videojuegos es de los pocos negocios que están experimentando crecimiento en sus mercados. Buena prueba de ello son los datos publicados por Microsoft que informan de que en 2.008 las ventas de su consola XBOX han crecido en un 22% en Europa, mientras que en España, en pleno desplome de industrias tan importantes como la automovilística o la del sector de la construcción, sus ventas han aumentado un 36%. Debido al crecimiento exponencial que ha sufrido la industria en los últimos 20 años, el proyecto Warbattle al que se dirige este documento pretende ser una base de partida a una apertura a este mercado, tanto para la universidad adoptándolo como base de trabajos posteriores, como para mí como aprendizaje del desarrollo de este tipo de software tan interesante como lucrativo. En los últimos años, por otro lado, ha aparecido un nuevo concepto de videojuego: los browsergames. Estos juegos basan su interfaz y jugabilidad bajo tecnologías Web. Para jugar a ellos únicamente es necesario disponer en casa de una conexión a internet y un navegador medianamente actualizado. Quizás por esa facilidad de acceso a este tipo de videojuegos, el crecimiento de éstos está siendo bastante importante. Warbattle (nombre con el que se designa el juego) es un browsergame en tiempo real ambientado en una Edad Media fantástica, al más puro estilo de los mundos creados por J.R.R.Tolkien, autor de una de las obras más populares de la literatura contemporánea, El Señor de los Anillos. A diferencia de otros títulos que se puedan encontrar en el mercado, Warbattle es un juego pensado para jugar de forma gratuita desde internet sin necesidad de realizar pesadas descargas que generan cierta desconfianza en los usuarios. En Warbattle múltiples jugadores, del orden de cientos e incluso miles, competirán entre sí por demostrar que son los mejores estrategas. El juego es de estrategia en tiempo real, en el que cada jugador podrá optar por caminos diferentes para crear sus imperios. Una característica especialmente atractiva del juego es la duración ilimitada del mismo. Warbattle está pensado para que una partida pueda alargarse en el tiempo tanto como lo desee el propio jugador, así podrán encontrarse cuentas de jugadores que lleven uno, dos o más años. El sistema de juego es muy sencillo con un interfaz agradable y atractivo a su vez. El tiempo que se debe emplear en él es relativo, cada jugador adoptará una estrategia u otra en función de sus gustos o posibilidades. De esta manera, si un 2 WarBattle jugador no puede entrar a diario seguramente opte por una estrategia defensiva en la que prime la producción como forma de obtener recursos sobre los ataques y saqueos a otros jugadores. Warbattle está pensado para un rango de jugadores cuya edad comprenda entre los 12 y los 50 años. Warbattle a su vez, está formado por una serie de elementos que dan vida al juego y que definen el universo que representa. Los más destacables son: Castillos desde los que los jugadores realizan todo tipo de acciones, construcción de edificios, unidades militares, etc. - Sistema de producción basado en recursos. - Construcción de elementos basado en gasto de recursos. Interacción pacífica o bélica entre jugadores mediante una red de unidades militares y defensivas. Sistema de coordenadas en el que se ubican los castillos que pertenecen a los jugadores. En definitiva, Warbattle es una idea innovadora que pretende captar multitud de usuarios gracias a un entorno atractivo y, sobre todo, divertido que permita desconectarse un rato de la rutina diaria. Figura 1.1.1: Interfaz del videojuego 3 Objetivos 2. Los objetivos que persigue este proyecto se pueden agrupar en dos conjuntos: 1. Diseño de una estructura que sirva para otros juegos. Durante la primera fase del proyecto se perseguirá realizar un diseño robusto y estable que pueda utilizarse para realizar otros juegos con diferentes elementos y con distintas ambientaciones. El objetivo perseguido es generar un diseño: - Robusto. Escalable Reutilizable. De sencilla interpretación. 2. Requisitos funcionales. Desde el punto de vista del juego en sí, se establece como objetivo principal crear un juego que sea: - 4 Entretenido. Ilimitado en el tiempo. Gratuito. Atractivo. Pensado para un rango de usuarios cuyas edades comprendan los 12 y los 50 años. Estable. WarBattle CAPÍTULO 2 Estado del arte 5 Historia de los videojuegos 1. Un videojuego es un programa de ordenador creado para el entretenimiento, basado en la interacción entre una o varias personas y un aparato electrónico que ejecuta dicho videojuego. En muchos casos, estos recrean entornos y situaciones virtuales en los que el jugador puede controlar a uno o varios personajes (o cualquier otro elemento de dicho entorno), para conseguir uno o varios objetivos por medio de unas reglas determinadas. Aunque inicialmente la idea de un videojuego fue concebida y patentada por Thomas T. Goldsmith Jr. y Estle Ray Mann en 1947, se considera como primer videojuego al creado por William Nighinbottham en 1958, el llamado Tenis Para Dos, que consistía en interceptar una bola que cruzaba la pantalla moviendo una línea que hacía de paleta. Su autor lo mostró como curiosidad científica, nunca patentó su invento y así fue que aproximadamente 15 años más tarde, concretamente en 1972, el juego fue perfeccionado y comercializado por Atari con el nombre de Pong convirtiéndose en el juego más relevante de la historia. Figura 2.1.1: Imagen del Pong Durante los años 80, el mundo de los videojuegos tuvo un fuerte crecimiento debido a la popularidad de los salones de máquinas recreativas. 6 WarBattle A esta década se la conoce como la de los 8 bits debido a los microprocesadores que empleaban las consolas de aquel momento. Durante esos años aparecieron diversos juegos tan populares como el Tetris de Alexey Pajitnov, el Super Mario Bros de Nintendo o el Bubble Bobble. Mientras en Japón se optaba por la fabricación de consolas con la aparición de la NES (Nintendo Entertainment System), en Europa los esfuerzos se dirigían hacia los microordenadores como el Commodore-64 o el Spectrum. Figura 2.1.2: Spectrum ZX de finales de los 80 A principios de los 90, el mercado de las videoconsolas se revolucionó por completo gracias a la aparición de los microprocesadores de 16 bits. Algunas de las primeras consolas que incorporaban este tipo de microprocesador fueron la Mega-Drive, la SNES o la NEO-GEO. En paralelo, iban apareciendo las versiones de los videojuegos de las consolas para los ordenadores de sobremesa aunque de una manera bastante tímida hasta casi finales de los 90. Algunos de los videojuegos que se sacaron para las plataformas PC fueron la saga Doom, Monkey Island, etc. Desde entonces, las diferentes compañías emprendieron una carrera por liderar el mercado, sacando, progresivamente, a la venta consolas de 32 y 64 bits. A principios del siglo XXI Sony lanzó su consola de 128 bits, la PS2 con la que se adelantó al resto de fabricantes, pasando a dominar los mercados de Europa Y EE.UU. 7 Durante los años siguientes fueron apareciendo nuevas consolas, como la Xbox 360 de Microsoft, la PS3 de Sony o la WII de Nintendo, siendo actualmente las tres empresas líderes del mercado a día de hoy. En el campo de los videojuegos para PC, la evolución ha sido exponencial desde la aparición del Pong hasta nuestros días. Aquel juego en 2D ha sido sustituido por juegos en 3D, con algoritmos avanzadísimos en el campo de la Inteligencia Artificial. Figura 2.1.3: Imagen del juego Assassins Creed de reciente aparición 8 WarBattle Los Browser Games 2. Un juego de navegador o browser game es todo aquel videojuego que se juega mediante un navegador web (Internet Explorer, Firefox, Opera, etc.) y por ende independientemente de la plataforma. Se caracteriza entonces por ser siempre una multiplataforma, que funciona en cualquier equipo que tenga un navegador web y no es necesario instalar nada en el ordenador ni realizar ninguna clase de descarga para poder jugar con ellos. Tan sólo es preciso ir a la página del juego en cuestión y crear una cuenta usuario. Dada la tecnología necesaria para su uso, los browser games existen prácticamente desde que se inventó la World Wide Web en 1993 y con ella el primer navegador web, aunque por supuesto han ido evolucionando al mismo tiempo que lo hacía Internet. Además de la clara ventaja que supone poder jugar desde cualquier ordenador o dispositivo del mundo, los browser games, al ser juegos online multijugador y muchos de ellos masivos, implican un juego cara a cara con cientos o miles de jugadores en todo el mundo, lo que permite una participación conjunta en el juego rompiendo el individualismo habitual de los videojuegos, pues se puede hacer amigos, crear alianzas, declarar guerras, etc. Además, los browser games suelen ser gratuitos aunque algunos tienen la posibilidad de enviar mensajes sms para ampliar las posibilidades de juego, sustentándose la mayoría gracias a la publicidad insertada en sus páginas. No obstante presentan asimismo una serie de inconvenientes, pues sólo se puede jugar online, ya que no se pueden descargar para jugar cuando no se esté conectado a Internet, se caracterizan por tener gráficos y sonido de baja calidad e incluso pueden llegar a no tener ni siquiera imágenes o animaciones y se consideran sumamente adictivos. La temática de estos juegos es muy variada, y va desde fantasía épica hasta escenarios futuristas. Al ser juegos en los que los gráficos no son tan importantes, destaca el componente de estrategia, por lo que no son habituales los juegos de matar o de carreras de coches, sino que la mayoría son juegos para pensar. Con todo ello, los browser games se han convertido en una opción de videojuego cada vez más atractiva y en una alternativa clara a los lanzamientos de las grandes multinacionales, pues muchos de ellos son desarrollados por un pequeño grupo de aficionados o por un programador de forma independiente. En cualquier caso, lo que es innegable es que algunos cuentan ya con varios miles de jugadores registrados, y son bastante populares sin ninguna gran campaña publicitaria ni de marketing. Los juegos más populares actualmente son Zepirates, Ogame, Medievol, Ikariam o Travian. 9 De ellos merece especial mención el Ogame, el browser game más conocido, el cual es un juego multijugador masivo on-line desarrollado por la empresa alemana Gameforge. El juego está implementado en el lenguaje de programación PHP, requiriendo únicamente un navegador común para poder jugarlo. Cada escenario de juego, denominado Universo, permite que se enfrenten simultáneamente hasta 16.500 jugadores. El primer universo apareció en el 2002 en Alemania, el cual sigue siendo el más popular. Existen versiones en diferentes idiomas como español, portugués, polaco, ruso, italiano, chino, japonés y danés. Periódicamente se añaden nuevos universos al juego, siendo el de más reciente aparición, concretamente el 12 de agosto de 2009, el Universo 59 Andrómeda, en la versión española. Figura 2.1: Imagen del juego OGame 10 WarBattle Metodología 3. La metodología que se usará para realizar el juego será la más común en la realización de proyectos software, la metodología en cascada. Este metodología establece un orden estricto en la realización de tareas, siendo requisito para empezar una tarea haber terminado la anterior. Las fases en que se divide la realización del proyecto son: - Análisis de requisitos: en esta fase se especifican los requerimientos del sistema. En este proyecto, además, se añadirá la tarea de creación del universo en el que discurre el juego, ya que no se parte con información al respecto. - Diseño: una vez recogidos los requisitos del sistema se realiza la tarea de plasmar el conocimiento recogido en un formato útil para poder fabricar el producto software más adelante. En esta fase se genera desde el diseño de la arquitectura escogida hasta los diagramas de flujo de las funciones que compondrán el sistema, pasando por el diseño de la base de datos, de clases, etc. - Programación: durante este período se recoge la información obtenida de la fase de diseño y se realiza la conversión a un lenguaje interpretable por el ordenador que generará el producto final. La tecnología que se va a utilizar es la siguiente: o Java como lenguaje de programación utilizando las APIs jdk 1.6 y J2EE. o XML como lenguaje de estructuración de ficheros de configuración. o XHTML y CSS 2.0 para generar los interfaces del juego. o Javascript para dar funcionalidad a los interfaces. o Ajax para los eventos asíncronos del juego. - Pruebas: en esta fase se realizan las pruebas pertinentes para determinar si el software generado cumple los requisitos esperados. 11 12 WarBattle CAPÍTULO 3 Análisis de requisitos 13 Introducción 1. En esta gran sección del proceso de construcción del sistema Warbattle se realizará el análisis de requisitos. El análisis de requisitos consiste, como su propio nombre indica, en analizar y estudiar los requisitos del sistema a construir. En el caso de este proyecto, no se cuenta con ninguna especificación externa ni con referentes pasados, por lo que además del habitual proceso de análisis será necesario realizar una definición de las reglas y elementos del universo Warbattle. El propósito principal de esta etapa es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema completo. Se pueden, además destacar los siguientes objetivos: - Describir un modelo del sistema utilizando el lenguaje de los desarrolladores. - Utilizar un lenguaje más formal para refinar detalles relativos a los requisitos del sistema. - Estructurar los requisitos de un modo que facilite su comprensión, desarrollo, modificación, y en general, su mantenimiento. Una vez realizada una breve definición del proceso de análisis de requisitos, se expondrán a continuación los puntos que lo formarán en este proyecto: - Estudio de la ambientación: se definirá el universo Warbattle de una forma, se podría decir, informal. Se especificarán todos los elementos y reglas del entorno mediante el lenguaje natural. - Modelo de dominio: una vez definido el entorno se procederá a su conceptualización mediante la técnica de UML 2.0 del modelo de dominio. - Modelo de casos de uso: a continuación del modelo de dominio se realizará un estudio de las funcionalidades que permitirá el juego. - Problemas encontrados y errores cometidos: se realizará una vez realizados todos los anteriores puntos un análisis del trabajo realizado, con el fin de que queden documentados los errores cometidos y los problemas encontrados para poder ser consultados en futuros trabajos y evitar caer otra vez en ellos. - Conclusiones: por último se realizará una valoración tanto técnica como personal del trabajo realizado. 14 WarBattle Estudio de la ambientación 2. En este capítulo se va a llevar a cabo el estudio de los elementos que formarán parte del juego. Puesto que Warbattle pretende ser un juego de estrategia en tiempo real, como en todos los juegos de este estilo debe tener un sistema de recursos que actúe de restricción y desbloqueo para la construcción de los demás elementos del juego. Cada elemento será citado, definido y descrito a lo lardo de este capítulo. 15 1. Elementos del juego 1.1 Castillos Serán los centros neurálgicos del juego. En ellos se desarrollará toda la actividad de los jugadores y se construirán todos los elementos de los que dispondrá para utilizar una estrategia u otra. Cada jugador dispondrá para empezar de un castillo ubicado en una casilla del mapa asignada automáticamente por el sistema mediante un algoritmo de balanceo que será descrito en capítulos posteriores. A medida que avance en el juego podrá aumentar el número de castillos bajo su dominio, de forma que podrá aumentar su poder respecto al resto de jugadores. 1.2 Recursos Como ha sido mencionado brevemente en el apartado anterior, los recursos constituyen una de las piedras angulares del juego. Cada tipo de recurso será empleado con diferentes fines, que se irán describiendo a lo largo de este capítulo. Los tipos de recurso disponibles para todos los jugadores serán: - Trigo. - Madera. - Piedra. - Hierro. - Especia. Para cada tipo de recurso existirá un tipo de productor (en adelante se utilizará el término productor para referirse a ello) que establecerá el número de unidades producidas por hora en la aldea en la que se encuentre. Cada productor tendrá un coste de aumento asociado diferente al resto de productores de otros recursos que vendrá definido por una función de crecimiento en el coste. En términos generales, la función que define el coste de aumento de nivel de un productor de un tipo de recurso será: Coste aumento = Coste base * 16 . WarBattle Observando la anterior función se puede apreciar claramente que es una función creciente en todo el dominio *1, ∞). El objetivo es que, al ser un juego de duración ilimitada, los costes de aumento de nivel supongan cada vez un reto mayor para el jugador. Por otro lado, dependiendo del productor que se quiera aumentar, será necesario disponer de uno o más tipos de recurso como se verá más adelante. Los parámetros de cada productor serán los siguientes: - - - - - Productor de trigo: o Tipo de recurso necesario: madera. Coste base = 40. Factor = 2. Productor de madera: o Tipo de recurso necesario: madera. Coste base = 60. Factor = 2. Productor de piedra: o Tipo de recurso necesario: madera. Coste base = 150. Factor = 2,2. Productor de hierro: o Tipo de recurso necesario: madera. Coste base = 300. Factor = 2,4. o Tipo de recurso necesario: piedra. Coste base = 100. Factor = 2,4. Productor de especia: o Tipo de recurso necesario: madera. Coste base = 500. Factor = 2,6. o Tipo de recurso necesario: piedra. Coste base = 200. Factor = 2,6. Como puede observarse de los anteriores datos, no todos los productores tienen una progresión en el coste igual. Por ejemplo, es más costoso reunir los recursos necesarios para aumentar el productor de hierro que el de madera. El objetivo por el que se establecen diferentes baremos para definir los costes en función del productor se debe a que lo que se pretende es que sea más difícil desbloquear ciertos elementos del juego que dependen de ciertos recursos con el fin de que el juego se alargue en el tiempo. 17 Una vez analizados los costes asociados a cada productor en función del nivel en el que se encuentren, va a ser explicado otro concepto fundamental asociado a los mismos: la producción. La producción no es más que el número de unidades que produce a la hora cada productor del tipo de recurso que lleva asociado. Así, se pretende establecer una relación directa entre el aumento de costes por nivel de los elementos y la producción de recursos. Para hacer esto posible, es necesario definir un sistema de producción común a todos los jugadores y dependiente del productor y del nivel al que se encuentre. Para ello se utilizará la siguiente función, que determina el número de unidades producidas de un tipo de recurso por su productor asociado. Unidades/hora = Coste base * factor * nivel del productor Al igual que en la función de costes de aumento, esta función también es creciente, pero con un nivel de crecimiento menor. Esto se debe a que el objetivo es retar al jugador a que tenga que esperar más tiempo para aumentar los elementos si depende únicamente de la producción de sus productores y necesite de estrategias adicionales para conseguir los recursos. Por último, puesto que el tiempo es un elemento crítico en el juego, será necesario establecer un sistema de cálculo de tiempo para el aumento de niveles. La función que define el tiempo en segundos de aumento de un productor viene definida por: Donde RecursoCoste hace referencia a cada coste por recurso asociado al productor. Más adelante, en el apartado 1.3 Edificios, se describirá la variable Herreros al describir la Fragua. 18 WarBattle 1.3 Edificios Los edificios son unos elementos que desempeñarán dos misiones fundamentales a lo largo del transcurrir del juego. Por un lado desbloquearán otros elementos (más información consultar el apartado 2. Restricciones de este capítulo) y por otro servirán para mejorar las prestaciones a nivel local de los castillos en los que se encuentren o prestaciones a nivel global del jugador que los posea. A continuación se describen los tipos de edificio disponibles en el juego: - Casa: permite aumentar en 20 unidades el número de soldados disponibles en una aldea. Figura 3.1.1: Imagen del tipo de edificio casa - Biblioteca: este edificio permite múltiples opciones simultáneamente. Una de ellas es la posibilitar la opción de aumentar las ciencias disponibles para el jugador. Por otro lado, también actúa de posible desbloqueador de ciencias, dependiendo del nivel en el que se encuentre. Por último, con cada aumento de nivel añade al número de eruditos del jugador el número de nivel al que acaba de ser construido. Así si, por ejemplo, un jugador disponía de 30 eruditos y acaba de construir una biblioteca al nivel 5, el número de eruditos se verá aumentado en 5, pasando a tener 35 eruditos en adelante. El término eruditos será explicado más adelante cuando se describa el papel que juega el tiempo en la investigación de ciencias. Figura 3.1.2: Imagen del tipo de edificio biblioteca - Academia militar: este edificio tiene una función prácticamente igual que la de la biblioteca, sólo que a diferencia de ésta en vez de interaccionar con las ciencias de un jugador, lo hace con las habilidades militares del mismo. Este edificio, además, en vez de eruditos aumenta el número de los maestros militares que será descrito cuando sean explicadas las habilidades militares. 19 Por último, la academia militar tiene la capacidad de desbloquear en ciertos niveles edificios como el cuartel o el taller de defensa (consultar apartado 2.Restricciones de este mismo capítulo para más información). Figura 3.1.3: Imagen del tipo de edificio academia militar - Fragua: este edificio tiene dos funciones principales: desbloquear otros edificios del castillo que no se encuentran disponibles y aumentar en cada nivel el número de herreros de la misma forma que la biblioteca aumenta el número de eruditos y la academia militar el número de maestros militares. Figura 3.1.4: Imagen del tipo de edificio fragua - Cuartel: en este edificio se construyen las unidades militares (consultar apartado 1.6 de este capítulo para más información). Además, según el nivel en el que se encuentre, estarán disponibles o no ciertas unidades para su construcción. Figura 3.1.5: Imagen del tipo de edificio cuartel 20 WarBattle - Taller de defensa: tiene el mismo funcionamiento que el cuartel pero para las unidades defensivas. Figura 3.1.6: Imagen del tipo de edificio taller de defensa - Mercado: en él se llevan a cabo los comercios con otros jugadores o con el sistema. El número de comercios activos en un castillo podrá ser, como máximo, igual al nivel del mercado. Figura 3.1.7: Imagen del tipo de edificio mercado - Almacén subterráneo: permite esconder parte de los recursos disponibles en un castillo al recibir ataques externos de otros jugadores. Cada nivel esconde un 5% de los recursos disponibles hasta un máximo de un 50%. Figura 3.1.8: Imagen del tipo de edificio almacén subterráneo Una vez analizados los diferentes tipos de edificios disponibles en los castillos se procede a explicar el funcionamiento de los costes asociados al aumento de nivel de los mismos. Para el aumento de nivel de los edificios se utilizará una función que definirá el coste de cada recurso necesario para llevar a cabo la acción. La función tiene el siguiente formato: Coste aumento = Coste base * . 21 Como se puede deducir fácilmente es una función creciente en todo el dominio *1, ∞). El objetivo es conseguir que el juego se alargue lo máximo posible y que aumentar cada nivel suponga un reto para el jugador. A continuación se describen los valores que se emplearán para cada edificio: - - - - - - 22 Casa: o Tipo de recurso necesario: madera. Coste base = 1.000. Factor = 1. Biblioteca: o Tipo de recurso necesario: madera. Coste base = 500. Factor = 2. Academia militar: o Tipo de recurso necesario: madera. Coste base = 200. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 50. Factor = 2. Fragua: o Tipo de recurso necesario: madera. Coste base = 1.000. Factor = 2,5. o Tipo de recurso necesario: piedra. Coste base = 200. Factor = 2,5. Cuartel: o Tipo de recurso necesario: madera. Coste base = 500. Factor = 2,5. o Tipo de recurso necesario: piedra. Coste base = 50. Factor = 2,5. Taller de defensa: o Tipo de recurso necesario: madera. Coste base = 500. Factor = 2,5. o Tipo de recurso necesario: piedra. Coste base = 50. Factor = 2,5. WarBattle - - Mercado: o Tipo de recurso necesario: madera. Coste base = 10.000. Factor = 3. o Tipo de recurso necesario: piedra. Coste base = 1.000. Factor = 3. Almacén subterráneo: o Tipo de recurso necesario: madera. Coste base = 20.000. Factor = 4. o Tipo de recurso necesario: piedra. Coste base = 5.000. Factor = 4. Por último, la función que define el tiempo de aumento de cada nivel de un edificio es de la siguiente forma (expresada en segundos): 23 1.4 Ciencias Las ciencias tienen una misión fundamental en el transcurso del juego: desbloquear edificios y otras ciencias. Además, como se verá más adelante, algunas desempeñan otras funciones. A diferencia de los edificios que actúan a nivel local, las ciencias actúan a nivel global en el jugador. Esto quiere decir que sus efectos se aplican a todos los castillos del jugador, no a uno sólo como ocurre con los edificios. A continuación se describen las ciencias disponibles en el juego: - Mando: cada nivel permite tener una misión adicional en curso. Por ejemplo, si un jugador tiene la ciencia mando en nivel 5, podrá tener, como máximo, cinco misiones simultáneas en curso. Figura 3.1.9: Imagen del tipo de ciencia mando - Herramientas: esta ciencia sirve para desbloquear otros elementos (consultar apartado 2. Restricciones de este capítulo). Figura 3.1.10: Imagen del tipo de ciencia herramientas - Forja del hierro: misma función que la ciencia Herramientas. Figura 3.1.11: Imagen del tipo de ciencia forja del hierro 24 WarBattle - Imperio: cada nivel permite al jugador poder colonizar una nueva posición para edificar un nuevo castillo. Así, por ejemplo, si un jugador tiene la ciencia Imperio en nivel 3 podrá tener 4 castillos (3 del nivel más el castillo con el que empieza). Figura 3.1.12: Imagen del tipo de ciencia imperio - Espionaje: sirve para mejorar las condiciones de espionaje con cada nivel (consultar apartado 1.9 Misiones de este capítulo). Figura 3.1.13: Imagen del tipo de ciencia espionaje - Ocultar bienes: misma función que la ciencia Herramientas. Figura 3.1.14: Imagen del tipo de ciencia ocultar bienes - Comercio: misma función que la ciencia Herramientas. Figura 3.1.15: Imagen del tipo de ciencia comercio 25 Al igual que con los productores o los edificios, las ciencias también tienen asociado un coste de aumento por nivel, que viene definido por la siguiente función: Coste aumento = Coste base * . Los valores de los parámetros de la función del coste para cada ciencia son los siguientes: - Mando: o Tipo de recurso necesario: madera. Coste base = 500. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 50. Factor = 2. - Herramientas: o Tipo de recurso necesario: madera. Coste base = 1.200. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 120. Factor = 2. - Forja del hierro: o Tipo de recurso necesario: madera. Coste base = 2.000. Factor = 2. o Tipo de recurso necesario: hierro. Coste base = 50. Factor = 2. - Imperio: o Tipo de recurso necesario: madera. Coste base = 50.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 5.000. Factor = 2. - Espionaje: o Tipo de recurso necesario: madera. Coste base = 2.200. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 500. Factor = 2. 26 WarBattle - - Ocultar bienes: o Tipo de recurso necesario: madera. Coste base = 10.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 1.000. Factor = 2. Comercio: o Tipo de recurso necesario: madera. Coste base = 30.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 3.000. Factor = 2. Igualmente, la función que define el tiempo de investigación es la siguiente: Puesto que las ciencias son un elemento global de un jugador, la variable Eruditos también lo será e, independientemente de donde tenga lugar el aumento de una biblioteca, será actualizado con cada evento de ese tipo. Por último, otra característica que le confiere que sea a nivel global es que, si bien las ciencias están disponibles para todos los castillos de un jugador, quizás no sean accesibles desde cualquiera de ellos. Esto se debe a que ciertos elementos puedan necesitar de más de un elemento que los desbloquee (consultar apartado 2. Restricciones de este mismo capítulo). 27 1.5 Habilidades militares Las habilidades militares tienen dos propósitos generales. Por un lado aumentan las bonificaciones de combate (consultar apartado 1.9 Misiones para obtener una información más detallada) y por otro lado desbloquean tanto otras habilidades como unidades militares y defensivas. Este tipo de elemento del juego se desarrolla en las academias militares. Actúan, al igual que las ciencias, a nivel global en un jugador, por lo que sus efectos repercuten en todos los castillos de un mismo jugador. Las habilidades militares del juego así como su descripción y uso son presentadas a continuación: - Ataque: cada nivel aumenta en uno el nivel de ataque de las unidades militares y defensivas. Figura 3.1.16: Imagen del tipo de habilidad militar ataque - Defensa: mismo efecto que la habilidad ataque pero sobre el nivel de defensa. Figura 3.1.17: Imagen del tipo de habilidad militar defensa - Vitalidad: mismo efecto que la habilidad ataque pero sobre el nivel de vida. Figura 3.1.18: Imagen del tipo de habilidad militar vitalidad 28 WarBattle - Velocidad: disminuye los tiempos de misión. Figura 3.1.19: Imagen del tipo de habilidad militar velocidad - Formación: cada nivel aporta un tipo de estrategia de formación para combate. Figura 3.1.20: Imagen del tipo de habilidad militar formación - Carga: cada nivel añade un ataque adicional sobre las unidades de tipo “Carga” (más información en el apartado 1.6 de este capítulo). Figura 3.1.21: Imagen del tipo de habilidad militar carga - Alcance: cada nivel añade un ataque adicional sobre las unidades de tipo “Distancia”. Figura 3.1.22: Imagen del tipo de habilidad militar alcance 29 - Asalto: aumenta el daño provocado por las unidades de tipo “Asalto”. Figura 3.1.23: Imagen del tipo de habilidad militar asalto Al igual que con los productores o los edificios, las habilidades militares también tienen asociado un coste de aumento por nivel, que viene definido por la siguiente función: Coste aumento = Coste base * . Los valores de los parámetros de la función del coste para cada habilidad militar son los siguientes: - Ataque: o Tipo de recurso necesario: madera. Coste base = 500. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 50. Factor = 2. - Defensa: o Tipo de recurso necesario: madera. Coste base = 800. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 80. Factor = 2. - Vitalidad: o Tipo de recurso necesario: madera. Coste base = 2.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 200. Factor = 2. 30 WarBattle - - - - - Velocidad: o Tipo de recurso necesario: madera. Coste base = 1.200. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 120. Factor = 2. Formación: o Tipo de recurso necesario: madera. Coste base = 20.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 2.000. Factor = 2. Carga: o Tipo de recurso necesario: madera. Coste base = 5.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 500. Factor = 2. Alcance: o Tipo de recurso necesario: madera. Coste base = 4.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 400. Factor = 2. Asalto: o Tipo de recurso necesario: madera. Coste base = 100.000. Factor = 2. o Tipo de recurso necesario: piedra. Coste base = 10.000. Factor = 2. Igualmente, la función que define el tiempo de desarrollo es la siguiente: 31 Puesto que las habilidades son un elemento global de un jugador, la variable Maestros militares también lo será e, independientemente de donde tenga lugar el aumento de una academia militar, será actualizado con cada evento de ese tipo. Por último, otra característica que le confiere que sea a nivel global es que, si bien las habilidades militares están disponibles para todos los castillos de un jugador, quizás no sean accesibles desde cualquiera de ellos. Esto se debe a que ciertos elementos puedan necesitar de más de un elemento que los desbloquee (consultar apartado 2. Restricciones de este mismo capítulo). 32 WarBattle 1.6 Unidades militares Las unidades militares son los elementos que permiten la interacción entre jugadores, así como entre castillos diferentes del propio jugador. Se podría realizar un símil en el que si los edificios, ciencias y habilidades conforman una estructura, las unidades forman la vida que se aloja en dichas estructuras. Por eso las unidades militares pueden realizar diferentes tipos de misiones (ver apartado 1.9 Misiones de este capítulo para más información). Las unidades militares pueden ser de cinco tipos: - Infantería: estas unidades suelen conformar la espina dorsal de cada ejército debido a su bajo coste y rendimiento aceptable. - Caballería: estas unidades tienen la característica de poder realizar cargas de ataque adicionales en cada turno, lo que les confiere un poder destructivo mayor que el de las infanterías. También su coste es más elevado. - A distancia: son las unidades que realizan, como su propio nombre indica, ataques a larga distancia. Poseen la característica Alcance que les proporciona probabilidades adicionales de realizar más de un ataque en un mismo turno. - Asalto: son las unidades más poderosas y, por tanto, las más costosas del juego. Su poder destructivo es mucho mayor que el de cualquier otro tipo de unidad. Su característica asalto les permite, además, infringir mayores daños sobre las tropas enemigas. - Especiales: estas unidades permiten realizar misiones especiales como espiar o colonizar (ver sección 1.9 Misiones). Todas las unidades militares tienen una serie de características que, combinadas con los bonificadores otorgados por las habilidades militares, son utilizados para realizar los cálculos de combate. Dichas características son: - Fuerza base. Defensa base. Vida base. Velocidad base. Carga máxima: capacidad máxima de transporte de recursos. Tipo de ataque: puede ser ninguno, de carga, de alcance o de asalto. El uso que se da de cada atributo se describirá más adelante en el capítulo 1.9 Misiones al explicar en detalle su funcionamiento. 33 A diferencia del resto de elementos vistos hasta el momento, las unidades militares no tienen niveles, por lo que no es necesario definir una función que determine el coste. No obstante esto no significa que no sea necesario definir unos costes para cada una de ellas, pues son, al fin y al cabo, también elementos construibles. Por otro lado, las unidades militares incorporan un nuevo tipo de coste asociado, además de los recursos vistos anteriormente (consultar apartado 1.2 Recursos). Este nuevo tipo de coste es el número de soldados que se necesitan reclutar. Como se vio en la sección 1.3 Edificios, este tipo de recurso especial se consigue mediante el edificio Casa. Los costes requeridos para construir una unidad de un tipo específico de unidad militar, así como los atributos de sus características a continuación: - Infantería ligera: o Costes: Hierro: 50 unidades. Soldados: 1. o Características: Fuerza: 2. Defensa: 3. Vida: 3. Velocidad: 5. Tipo de ataque especial: ninguno. Fuerza de ataque especial: 0. Carga máxima: 100 unidades. Figura 3.1.24: Imagen del tipo de unidad militar infantería ligera 34 WarBattle - Infantería pesada: o Costes: Hierro: 500 unidades. Soldados: 5. o Características: Fuerza: 6. Defensa: 8. Vida: 8. Velocidad: 4. Tipo de ataque especial: ninguno. Fuerza de ataque especial: Carga máxima: 200. Figura 3.1.25: Imagen del tipo de unidad militar infantería pesada - Caballería ligera: o Costes: Hierro: 200 unidades. Soldados: 5. o Características: Fuerza: 3. Defensa: 2. Vida: 5. Velocidad: 10. Tipo de ataque especial: carga. Fuerza de ataque especial: 2. Carga máxima: 50 unidades. Figura 3.1.26: Imagen del tipo de unidad militar caballería ligera 35 - Caballería pesada: o Costes: Hierro: 2.000 unidades. Soldados: 25. o Características: Fuerza: 8. Defensa: 7. Vida: 10. Velocidad: 8. Tipo de ataque especial: carga. Fuerza de ataque especial: 5. Carga máxima: 100 unidades. Figura 3.1.27: Imagen del tipo de unidad militar caballería pesada - Arquero: o Costes: Hierro: 100 unidades. Soldados: 3. o Características: Fuerza: 1. Defensa: 1. Vida: 2. Velocidad: 5. Tipo de ataque especial: a distancia. Fuerza de ataque especial: 2. Carga máxima: 20 unidades. Figura 3.1.28: Imagen del tipo de unidad militar arquero 36 WarBattle - Saetero: o Costes: Hierro: 1.000 unidades. Soldados: 15. o Características: Fuerza: 3. Defensa: 4. Vida: 5. Velocidad: 5. Tipo de ataque especial: a distancia. Fuerza de ataque especial: 6. Carga máxima: 50 unidades. Figura 3.1.29: Imagen del tipo de unidad militar saetero - Dragón: o Costes: Hierro: 100.000 unidades. Soldados: 500. o Características: Fuerza: 12. Defensa: 15. Vida: 20. Velocidad: 2. Tipo de ataque especial: asalto. Fuerza de ataque especial: 10. Carga máxima: 10 unidades. Figura 3.1.30: Imagen del tipo de unidad militar dragón 37 - Espía: o Costes: Hierro: 10 unidades. Soldados: 1. o Características: Fuerza: 0. Defensa: 0. Vida: 1. Velocidad: 20. Tipo de ataque especial: ninguno. Fuerza de ataque especial: 0. Carga máxima: 0 unidades. Figura 3.1.31: Imagen del tipo de unidad militar espía - Convoy: o Costes: Piedra: 500 unidades. Soldados: 20. o Características: Fuerza: 1. Defensa: 1. Vida: 2. Velocidad: 10. Tipo de ataque especial: ninguno. Fuerza de ataque especial: 0. Carga máxima: 500 unidades. Figura 3.1.32: Imagen del tipo de unidad militar convoy 38 WarBattle Por último, el tiempo que se tarda en construir una unidad de un tipo de unidad específico es igual al número de unidades (sin incluir los soldados) en segundos. Así si, por ejemplo, se construyen 10 unidades del tipo de unidad caballería ligera que tienen cada una de ellas un coste de 200 unidades de hierro, el tiempo de construcción de una serán 200 segundos y el de todas ellas en conjunto de de 200 * 10 = 2.000 segundos. 39 1.7 Unidades defensivas Este tipo de elemento tiene como función, como su propio nombre indica, el de defender los castillos asediados por otros jugadores. Esto no quiere decir que en un ataque las unidades militares estacionadas en un castillo no participen en él, puesto que se ven igualmente afectadas, sino que están ideadas para que esa sea su única función. Las unidades defensivas son en varios aspectos muy similares a las unidades militares, aunque a diferencia de estas últimas su posición es fija y no pueden desplazarse. Esto significa que aquellas unidades defensivas que sean construidas en un castillo tendrán todo su ciclo de vida siempre en el mismo. El hecho de que su estacionamiento sea fijo les hace prescindir de ciertos atributos que tienen las unidades militares que son los relacionados con el movimiento. Así pues, los atributos que definen a las unidades defensivas son los siguientes: - Fuerza base. - Defensa base. - Vida base. Esos tres atributos, no obstante, también se ven afectados por los mismos bonificadores que afectan a las unidades militares, sólo que este tipo de elementos se verán influenciados en los tres atributos anteriormente mencionados. Por otro lado, al igual que sucede con las unidades militares, no requieren de función de crecimiento para estimar el coste de construcción puesto que no tienen niveles. Sin embargo, a este tipo de unidades se les excluye el coste por soldados. A continuación se describen los tipos de unidades defensivas que se pueden encontrar en el juego junto a sus atributos y costes: 40 WarBattle - Lanceros: o Costes: Hierro: 10 unidades. o Características: Fuerza: 2. Defensa: 4. Vida: 2. Figura 3.1.33: Imagen del tipo de unidad defensiva lancero - Piqueros: o Costes: Hierro: 50 unidades. o Características: Fuerza: 4. Defensa: 6. Vida: 4. Figura 3.1.34: Imagen del tipo de unidad defensiva piquero 41 - Ballesteros: o Costes: Hierro: 200 unidades. o Características: Fuerza: 6. Defensa: 8. Vida: 6. Figura 3.1.35: Imagen del tipo de unidad defensiva ballestero - Calderos de aceite: o Costes: Hierro: 5.000 unidades. o Características: Fuerza: 10. Defensa: 4. Vida: 2. Figura 3.1.36: Imagen del tipo de unidad defensiva calderos de aceite 42 WarBattle - Balistas: o Costes: Hierro: 50.000 unidades. o Características: Fuerza: 15. Defensa: 10. Vida: 10. Figura 3.1.37: Imagen del tipo de unidad defensiva balista Por último, el tiempo que se tarda en construir una unidad de un tipo de unidad defensiva específico es igual al número de unidades que cuesta en segundos. Así si, por ejemplo, se construyen 5 unidades de lanceros que tienen cada una de ellas un coste de 10 unidades de hierro, el tiempo de construcción de una serán 10 segundos y el de todas ellas en conjunto de de 10 * 5 = 50 segundos. 43 1.8 Mapa y sistema de coordenadas Un elemento fundamental del universo Warbattle es su sistema de coordenadas. El mapa sobre el que se aloja está dividido en tierras que a su vez se dividen en sector y que, por último, se dividen en posiciones. El mapa completo consta de 16 tierras que conforman un cuadrado dividido en 16 posiciones como se puede observar en la siguiente figura adjunta: Tierra 1 Tierra 2 Tierra 3 Tierra 4 Tierra 5 Tierra 6 Tierra 7 Tierra 8 Tierra 9 Tierra 10 Tierra 11 Tierra 12 Tierra 13 Tierra 14 Tierra 15 Tierra 16 Figura 3.1.38: División del mapa en tierras De igual manera, cada tierra se encuentra dividida a su vez en 49 sectores de la siguiente forma: Sector 1 Sector 2 Sector 3 Sector 4 Sector 5 Sector 6 Sector 7 Sector 8 Sector 9 Sector 10 Sector 11 Sector 12 Sector 13 Sector 14 Sector 15 Sector 16 Sector 17 Sector 18 Sector 19 Sector 20 Sector 21 Sector 22 Sector 23 Sector 24 Sector 25 Sector 26 Sector 27 Sector 28 Sector 29 Sector 30 Sector 31 Sector 32 Sector 33 Sector 34 Sector 35 Sector 36 Sector 37 Sector 38 Sector 39 Sector 40 Sector 41 Sector 42 Sector 43 Sector 44 Sector 45 Sector 46 Sector 47 Sector 48 Sector 49 Figura 3.1.39: División de las tierras en sectores 44 WarBattle Por último cada sector se encuentra dividido en 16 posiciones como se muestra en la siguiente figura: Posición 1 Posición 2 Posición 3 Posición 4 Posición 5 Posición 6 Posición 7 Posición 8 Posición 9 Posición 10 Posición 11 Posición 12 Posición 13 Posición 14 Posición 15 Posición 16 Figura 3.1.40: División de los sectores en posiciones Como se ha podido observar en las anteriores figuras, este sistema de coordenadas se basa en posiciones adyacentes similares a una matriz nxn. Los castillos se encuentran alojados en posiciones, teniendo sus coordenadas el siguiente formato: [ Tierra : Sector : Posición ]. Estas coordenadas son únicas en todo el dominio de Warbattle y cada una sólo puede ser ocupada por un único castillo. Así, con este sistema de coordenadas, el sistema calculará la distancia entre dos posiciones respecto de su distancia en cada matriz, siendo, por ejemplo, para las coordenadas [1:1:1] la posición más alejada del mapa las coordenadas [16:49:16] y las más cercanas las coordenadas [1:1:2], [1:1:5] y [1:1:6]. Por otro lado, el sistema tendrá en cuenta si las posiciones recorridas para llegar a un punto estén dentro de un mismo sector o de una misma tierra, en cuyo caso las distancias serán, en principio, más cortas que al cruzar sectores o tierras. No obstante, puesto que cada posición recorrida dentro de un sector equivale a un kilómetro (realizando una transformación al sistema métrico), el sistema debe ser capaz de calcular y ponderar las distancias en aquellos casos en los que sean elevadas con el fin de que una misión no tarde un tiempo excesivo para el jugador. 45 Por último, aunque ya se describirá con más detenimiento a la hora de realizar el diseño del sistema la forma en que se asignan automáticamente las posiciones, se hará en este epígrafe una breve descripción del mismo. El mecanismo de asignación consistirá en una asignación que aporte equilibrio al mapa, intentando ocupar todos los sectores del mismo. Para ello deberá tener memoria de cuál fue la última posición ocupada para proceder a la siguiente asignación. 46 WarBattle 1.9 Misiones Este tipo de acción es el que pretende darle un atractivo mayor al juego. Con ellas los jugadores interaccionarán entre sí, los recursos de los castillos podrán ser transportados de uno a otro, etc. Las misiones sólo podrán ser realizadas por las unidades militares, aunque, como se irá viendo a lo largo de esta sección no todas las unidades podrán realizar cualquier tipo de misión. A continuación serán expuestas y explicadas en detalle cada una de ellas: - Transporte: esta misión, como su propio nombre indica, permite transportar recursos entre dos castillos diferentes. La cantidad transportada vendrá determinada por la suma de las capacidades máximas de las unidades involucradas en dicha misión. Una vez parten del castillo de origen los recursos transportados serán restados de los almacenados en dicho castillo. Al llegar a su destino entregarán la mercancía, actualizando así los recursos del castillo destino. - Ataque: se enviarán unidades militares a atacar al castillo de otro jugador con el objetivo de destruir su fuerza militar y de robarle parte de los recursos que tenga almacenados en el instante del ataque en el castillo. El algoritmo empleado para el ataque será explicado en detalle en el apartado de diseño correspondiente. - Espionaje: para esta misión será necesario enviar espías a ella para que tenga efecto. Su objetivo es conseguir información sobre los elementos bélicos (unidades militares, defensivas, habilidades militares) que se encuentren en el momento del espionaje en el castillo objetivo. El nivel de información “robada” será proporcional al nivel de la ciencia espionaje del jugador que espía respecto a la del jugador que es espiado. El algoritmo empleado para los espionajes será explicado en detalle en el apartado de diseño correspondiente. - Colonización: con este tipo de misión el jugador podrá construir nuevos castillos desde cero. Para que esta misión pueda llevarse a cabo será necesario cumplir tres requisitos: o En la misión debe ir, por lo menos, un Convoy. o El nivel de la ciencia Imperio del jugador que quiere construir un nuevo castillo debe ser mayor que el número de castillos ya construidos (sin incluir el castillo inicial). o La casilla que se quiere colonizar no debe estar ocupada por ningún castillo, ya sea del propio jugador como de otro. 47 El tiempo de viaje vendrá determinado como se pudo ver en los anteriores apartados por dos factores: - Distancia entre la posición de origen y la de destino. - Velocidad de las tropas involucradas. Por último, el número máximo de misiones que puede un jugador tener activas a la vez debe ser menor o igual al nivel al que tenga la ciencia Mando. 48 WarBattle 2. Restricciones En esta sección se analizarán las restricciones que van ligadas a la naturaleza del universo Warbattle. Elemento bloqueado CIENCIAS Mando Herramientas Forja del hierro Imperio Espionaje Ocultar bienes Comercio HABILIDADES MILITARES Ataque Defensa Vitalidad Velocidad Formación Carga Alcance Asalto EDIFICIOS Almacén subterráneo Fragua Cuartel Academia militar Mercado Taller de defensa Elemento que desbloquea Biblioteca nivel 2 Biblioteca nivel 1 Biblioteca nivel 2 Herramientas nivel 3 Biblioteca nivel 8 Mando nivel 7 Biblioteca nivel 5 Mando nivel 5 Biblioteca nivel 10 Imperio nivel 4 Biblioteca nivel 8 Academia militar nivel 2 Academia militar nivel 3 Academia militar nivel 5 Ataque nivel 2 Academia militar nivel 4 Academia militar nivel 8 Academia militar nivel 4 Ataque nivel 6 Academia militar nivel 4 Velocidad nivel 2 Academia militar nivel 10 Ataque nivel 10 Ocultar bienes nivel 8 Forja del hierro nivel 4 Fragua nivel 2 Mando nivel 3 Mando nivel 5 Comercio nivel 2 Fragua nivel 6 Mando nivel 5 49 UNIDADES MILITARES Infantería ligera Infantería pesada Caballería ligera Caballería pesada Arquero Saetero Dragón Espía Convoy UNIDADES DEFENSIVAS Lanceros Piqueros Ballesteros Calderos de aceite Balistas 50 Cuartel nivel 1 Academia militar nivel 2 Ataque nivel 2 Cuartel nivel 5 Academia militar nivel 4 Ataque nivel 4 Cuartel nivel 3 Academia militar nivel 4 Carga nivel 2 Cuartel nivel 7 Academia militar nivel 7 Carga nivel 8 Cuartel nivel 4 Academia militar nivel 4 Alcance nivel 2 Cuartel nivel 6 Academia militar nivel 7 Alcance nivel 8 Cuartel nivel 12 Academia militar nivel 12 Asalto nivel 6 Cuartel nivel 4 Academia militar nivel 4 Velocidad nivel 4 Cuartel nivel 2 Academia militar nivel 4 Velocidad nivel 4 Taller de defensa nivel 2 Academia militar nivel 4 Defensa nivel 1 Taller de defensa nivel 4 Academia militar nivel 6 Defensa nivel 4 Taller de defensa nivel 6 Academia militar nivel 6 Defensa nivel 6 Taller de defensa nivel 6 Academia militar nivel 7 Defensa nivel 8 Taller de defensa nivel 12 Academia militar nivel 12 Defensa nivel 10 WarBattle Modelo de dominio 3. En este capítulo se recoge la información obtenida utilizando el modelo de dominio para representar mediante UML 2.0 la realidad del sistema que será desarrollado más adelante. Antes de empezar con el análisis, conviene recordar la definición de modelo de dominio para facilitar la comprensión del mismo. Un modelo de dominio consiste en uno o más diagramas UML que muestran: Los conceptos básicos del dominio del problema. Sus propiedades más importantes. Las relaciones importantes entre dichos conceptos. A pesar de su utilidad no todos los proyectos software requieren de su realización, generalmente porque su tamaño no es lo suficientemente grande como para requerir de una herramienta que ordene y relacione conceptos. En el caso del proyecto Warbattle es una herramienta más que necesaria, se podría decir que es imprescindible. Una vez realizado un buen modelo de dominio, el trabajo posterior de diseño comienza a ser abordable. De otra forma, hubiesen existido problemas de ensamblaje de nuevos conceptos en módulos nuevos, con su consiguiente pérdida de tiempo al tener que rehacer trabajo. Una vez vistas las ventajas aportadas por esta técnica, se procede a separar los conceptos que van a ser tratados en grandes grupos para poder reflejar cómodamente los diagramas. Antes de empezar es necesario destacar que, de aquí en adelante, se sustituirá el término castillo por el de aldea, puesto que a nivel de análisis y diseño refleja mejor su función en el sistema. Estos grupos son: El entorno del jugador a nivel global. El entorno de las aldeas. Sistema de producción. Sistema de costes. Unidades militares. Unidades defensivas. Restricciones. Misiones. Sistema de coordenadas. 51 3.1 Entorno del jugador a nivel global En esta sección se intentará recoger toda la información que el sistema debe reflejar respecto a los elementos que están directamente ligados a un jugador. Esta información se recoge en el siguiente diagrama: Figura 3.2.1: Diagrama del modelo de dominio del entorno del jugador a nivel global El diagrama muestra las siguientes entidades y relaciones: - Jugador: hace referencia, como su nombre indica, al propio jugador. Para poder identificarle de los demás deberá tener un nombre único del resto. Los otros dos atributos que se muestran, contraseña y email son necesarios para una correcta gestión de éstos. - Características jugador: son las propiedades de la partida del jugador a nivel global. Sus atributos son: eruditos y maestros militares, que ya fueron explicados en el anterior capítulo. - Aldea: son los centros de actividad de los jugadores como ya se vio en el anterior capítulo. Por el momento, sólo interesa recoger la información sobre su nombre y si es capital o no. Esto significa que es la aldea de la que parte inicialmente el jugador o ha sido creada por él. 52 WarBattle Por otro lado, como se puede apreciar en la relación [1,*], un jugador puede tener una o varias aldeas, no obstante, una aldea sólo podrá pertenecer a un jugador. - Ciencia: esta entidad sólo tiene un atributo, el nivel. Esto se debe a que esta entidad se refiere exclusivamente al objeto en particular de la ciencia que posee el jugador. Puesto que todos los jugadores utilizan los mismos tipos de ciencia, el resto de información común será excluida en otra entidad diferente, Tipo ciencia. Como se puede observar en el diagrama, cada ciencia pertenece a un único jugador, pudiendo este último tener un número indeterminado de ciencias bajo su supervisión. - Tipo ciencia: es la información sobre cada ciencia que es común a todos los usuarios. Para el nivel de estudio actual sólo interesa saber que tiene un nombre y una descripción únicos y distintos del resto de tipos de ciencia. Más adelante se irán viendo otras relaciones que parten de esta entidad del modelo de dominio. Al observar el diagrama se aprecia que cada ciencia debe pertenecer a un tipo de ciencia, lo que en la otra dirección no se refleja, sino que cada tipo de ciencia puede múltiples ciencias que estén relacionadas con ella. - Habilidad militar: de estructura muy similar a las ciencias, este objeto especifica las habilidades militares de un jugador, cuya información contenida es el nivel al que se encuentra y el tipo de habilidad que es, que se refleja en la relación [*,1] con tipo habilidad. - Tipo habilidad: muy similar también a tipo ciencia, pero a diferencia de ésta, su contenido refleja la información sobre los tipos de habilidades comunes a todos los usuarios. 53 3.2 Entorno de las aldeas En el anterior punto se ha recogido toda la información relativa al entorno del jugador a nivel global. En esta sección se va a proceder a describir los elementos pertenecientes a cada aldea. Los elementos estáticos (en referencia a aquellos elementos que una vez dados de alta no sufrirán baja, aunque si modificaciones en los valores de sus atributos) de una aldea son los que se pueden observar en el siguiente diagrama: Figura 3.2.2: Diagrama del modelo dominio Las entidades y relaciones del diagrama son las siguientes: - Aldea: puesto que ahora se ha analizado el carácter local de las aldeas y los elementos que pertenecen a ella, se han añadido un par de atributos que reflejan el estado de la misma en el juego. Estos atributos son: o Herreros: indican el número de herreros que tiene la aldea. o Soldados disponibles para construir unidades militares en una aldea. - Recurso: es la cantidad de unidades de cada recurso que hay disponibles en una aldea. Cada recurso sólo podrá ser de un tipo de recurso. Por otro lado, cada recurso sólo podrá pertenecer a una aldea. - Tipo recurso: recoge la información sobre el comportamiento y características de cada tipo de recurso. En este diagrama sólo interesa hacer referencia a información de tipo identificativa como el nombre y su 54 WarBattle descripción. En los siguientes puntos se volverá a utilizar esta entidad y se aumentará la información asociada a ella. - Productor: son los elementos que se encargan de producir recursos en una aldea. Puesto que todas las aldeas del juego tendrán el mismo tipo de productor, es necesario dividir la parte que es estática y que define las características del mismo de la parte que es distinta o no en cada aldea. La información cambiante, por tanto, se recoge en esta entidad. Esa información es el nivel al que se encuentre en un momento dado el productor. Así, cada productor pertenece a una única aldea, mientras que ésta puede tener múltiples productores. - Tipo productor: recoge información de tipo estática sobre los tipos de productores que existen en el juego. Más adelante se definirán más características de los mismos. En este momento sólo interesa conocer que tiene información identificativa como el nombre y la descripción. También se pueden extraer dos conceptos fundamentales del anterior diagrama: o Un productor sólo puede ser de un tipo de productor. o Un tipo de productor produce un tipo de recurso que sólo puede ser producido en un tipo de productor específico. - Edificio: recoge la información sobre el estado de los edificios en una aldea. Cada edificio sólo puede ser de un tipo de edificio específico. La información relativa al tipo de edificio será descrita en la entidad tipo edificio. Aquí sólo se recoge el nivel al que se encuentre una instancia de un edificio. Por otro lado, en una aldea puede haber múltiples edificios, mientras que un edificio sólo puede pertenecer a una aldea. - Tipo edificio: esta entidad abarca la información sobre los tipos de edificio disponibles en el juego. Será utilizada por todos los edificios que sean del tipo asociado de todas las aldeas. Más adelante se aumentará la información asociada a los tipos de edificios, pero por el momento es suficiente conocer que cada tipo de edificio tiene un nombre y una descripción del mismo. 55 3.3 Sistema de producción En esta sección se va a tratar el análisis del sistema de producción, haciendo un estudio de los elementos que intervienen en este proceso. Como ya se vio en el capítulo anterior dedicado al estudio de la ambientación del universo Warbattle, la producción de un tipo de productor venía definida por la siguiente función: Unidades/hora = Coste base * factor * nivel del productor El siguiente diagrama recoge los elementos participantes, las relaciones entre ellos y los atributos que los componen: Figura 3.2.3: Diagrama del modelo de dominio del sistema de producción Los elementos participantes en el diagrama son los siguientes: - Tipo recurso: su contenido es igual que el que se vio en el anterior punto. En esta ocasión aparece una nueva relación asociada a esta entidad, la que le une a la entidad producción. 56 WarBattle Esta relación significa que para cada tipo de recurso existe una función de producción que viene definida por los atributos de la entidad producción como se puede comprobar en la función adjunta anterior al diagrama. - Producción: esta entidad refleja el concepto de la fórmula que determina la producción de un tipo de recurso cuando un productor está a un determinado nivel. Sus atributos, por tanto, son los equivalentes a las variables que determinan la producción. o Factor. o Producción base. Por otro lado, la variable que falta para calcular la producción se extrae de la entidad productor, que va ligada a la entidad producción. - Productor: la información de este elemento no se ve alterada en este punto respecto al anterior. Como se ha comentado al describir la entidad producción, ahora el atributo nivel tiene una nueva función, la de participar en la función de cálculo de la producción de recursos. - Recurso: esta entidad ve modificado su contenido, ya que en este punto es necesario añadirle un nuevo atributo. Este atributo refleja la producción por hora del tipo de recurso de la aldea, que será actualizado respecto a la producción de un tipo de recurso de la aldea. Por eso, la relación que une producción y recurso es meramente informativa, pues la unión entre ambos sólo existirá en los momentos en que un productor sea actualizado por aumentar de nivel. 57 3.4 Sistema de costes En este punto se va a plasmar toda la información necesaria para los procesos de cálculo de costes para el aumento de niveles en cualquier elemento que lleve asociado un coste. Los elementos del universo Warbattle que cuestan recursos, como se vio en el anterior capítulo estudio de la ambientación, son: - Productores. - Edificios. - Ciencias. - Habilidades militares. - Unidades militares. - Unidades defensivas. Como se vio también en el anterior capítulo, la fórmula de cálculo para el coste de aumentar un nivel un elemento era: Coste aumento = Coste base * . El siguiente diagrama muestra los elementos participantes así como las relaciones existentes entre ellos y los atributos que las definen: Figura 3.2.4: Diagrama del modelo de dominio del sistema de costes 58 WarBattle Las entidades colaboradoras en el diagrama anterior son: - Tipo recurso: esta entidad ya ha sido descrita anteriormente, por eso aparece vacía de atributos. En este contexto tiene significado completo, pues los costes van asociados, cada uno, a un tipo de recurso específico. - Coste nivelado: es el coste para un tipo de recurso de aumentar un tipo de elemento con nivel. Esta entidad tiene como atributos las variables que definen la función de coste a excepción del nivel que será recogida a la hora de calcular el coste de la instancia que almacene dicha información. - Tipo nivelado: esta entidad recoge las características comunes a todos los tipos de elementos cuyas instancias poseen el atributo nivel. El motivo de que puedan heredar de esta clase se debe a que todas ellas utilizan la misma función para el cálculo del coste, variando de unas a otras los parámetros. - Tipo productor: entidad ya descrita en anteriores puntos. Hereda de tipo nivelado para calcular el coste de aumento de nivel. - Tipo edificio: entidad ya descrita en anteriores puntos. Hereda de tipo nivelado para calcular el coste de aumento de nivel. - Tipo ciencia: entidad ya descrita en anteriores puntos. Hereda de tipo nivelado para calcular el coste de aumento de nivel. - Tipo habilidad: entidad ya descrita en anteriores puntos. Hereda de tipo nivelado para calcular el coste de aumento de nivel. - Coste militar: define los costes asociados a los tipos de unidades militares. Puesto que este tipo de elementos no tienen la propiedad nivel, los costes son constantes y vienen definidos por el atributo coste base. - Tipo militar: abarca a los dos tipos de unidades de combate, las unidades militares y las unidades defensivas. - Tipo unidad: son los tipos de unidades militares del juego. Más adelante se describirán en mayor detalle, aunque de momento es suficiente saber que para estimar su coste hereda de la entidad tipo militar. - Tipo defensa: son los tipos de unidades defensivas del juego. Más adelante se describirán en mayor detalle, aunque de momento es suficiente saber que para estimar su coste hereda de la entidad tipo militar. 59 3.5 Unidades militares A continuación se procederá al análisis de las unidades militares y su relación con otros elementos del universo Warbattle. Las unidades militares forman tropas que consisten en escuadrones de varias unidades de un mismo tipo de unidad militar. Las tropas a su vez forman parte de ejércitos, que pueden, o bien estar estacionados en una aldea, o bien participar en una misión. A su vez, como ya se vio anteriormente, los tipos de unidades militares tienen una serie de características especiales que se aplican en los combates. Toda esta información queda recogida en el siguiente diagrama: Figura 3.2.5: Diagrama del modelo de dominio de las unidades militares La explicación de las entidades, las relaciones entre ellas y sus atributos viene a continuación: - Tipo unidad: define los tipos de unidades militares disponibles en el juego. Esta información es común para todos los jugadores y de contenido estático. Como se puede observar, tiene varios atributos, que son: o Nombre del tipo de unidad. o Descripción del tipo de unidad. o Fuerza base para un determinado tipo de unidad. 60 WarBattle o Defensa base para un determinado tipo de unidad. o Puntos de vida base para un determinado tipo de unidad. o Velocidad base para un determinado tipo de unidad. o Carga máxima de transporte del tipo de unidad. o Tipo de ataque especial si es que tiene alguno. o Poder del tipo de ataque especial si es que tiene. o Soldados necesarios para poder construir una unidad del tipo de unidad militar deseado. Por último, esta entidad es la misma que la que fue expuesta al describir los costes, sólo que su contenido ha sido aquí ampliado. - Tropa: representa los escuadrones formados por un tipo de unidad militar dentro de un ejército. Dentro de esta entidad es necesario recopilar el número de unidades disponibles en el ejército de un tipo de unidad militar específica. - Ejército: agrupa las diferentes tropas que forman parte de, valga la redundancia, un ejército. Como se puede observar en el diagrama, un ejército sólo podrá estar, o bien estacionado en una aldea, o bien ejerciendo una misión. - Misión: esta entidad representa las misiones de un jugador. Más adelante será explicada en mayor profundidad, pero de momento es suficiente saber que puede ser uno de los dos destinos de uso de un ejército. Por otro lado, en una misión sólo puede estar involucrado un ejército que estuviese en una aldea. - Aldea: como se puede comprobar en el diagrama, esta entidad se encuentra vacía de atributos en él. Esto se debe a: o Los atributos requeridos hasta el momento de análisis ya han sido definidos en anteriores diagramas. o Al definir las unidades militares no han aparecido atributos relevantes que amplíen la definición de la entidad. Por último, como se observa en la relación [1, 0,1] entre aldea y ejército, si bien un ejército puede no estar estacionado en una aldea, una aldea no puede tener estacionados más de un ejército al mismo tiempo. 61 3.6 Unidades defensivas El siguiente caso de estudio es el que abarca las relaciones con las unidades defensivas del juego. La estructura que define las unidades defensivas y su entorno es muy similar a la que define las unidades militares. No obstante, existen dos diferencias fundamentales entre ellas, que son: - Las unidades defensivas, como se vio durante el estudio de la ambientación (ver capítulo 1 Estudio de la ambientación) son elementos inamovibles dentro de una aldea. Esto significa que sólo pueden ejercer su función, la de defender, en el interior de una aldea. Por ello, así como las unidades militares podían, o bien encontrarse estacionadas en una aldea, o bien estar participando en una misión, las unidades defensivas sólo pueden estar estacionadas en una aldea, en la que se llevará a cabo todo su ciclo de vida. - Como se vio en el anterior punto, las unidades militares tienen una serie de atributos que definen sus características de combate (fuerza, defensa y vida) y otras características (especiales y relacionadas con las misiones). Las unidades defensivas, al permanecer siempre estacionadas en una aldea, no requieren de las características no relacionadas con el combate que poseen las unidades militares. El siguiente diagrama muestra las relaciones y entidades recién descritas: Figura 3.2.6: Diagrama del modelo de dominio de las unidades defensivas 62 WarBattle A continuación se explican las entidades que participan en el anterior diagrama: - Tipo defensa: recoge la información estática y relativa de los tipos de unidades defensivas del juego. Esta información es compartida y utilizada por todos los usuarios. Define las características de cada tipo de unidad defensiva mediante los siguientes atributos: o Nombre del tipo de unidad defensiva. o Descripción del tipo de unidad defensiva. o Fuerza base del tipo de unidad defensiva. o Defensa base del tipo de unidad defensiva. o Vida base del tipo de unidad defensiva. Los atributos fuerza, defensa y vida son utilizados, al igual que sucedía con las unidades militares, para realizar los cálculos necesarios para estimar el resultado de los combates. - Tropa defensa: esta entidad agrupa por tropas, de una forma similar a la entidad tropa del grupo unidades militares, a todas las unidades defensivas de un mismo tipo. Su único atributo, unidades, define el número de soldados de un tipo de unidad defensiva que forman parte de las defensas de una aldea. Ese atributo es de carácter dinámico, pues se verá aumentado al construir más unidades, o disminuido, si procede, tras un combate. - Defensa aldea: su estructura y función son prácticamente idénticas a las de la entidad ejército del grupo unidades militares. Su propósito es el de agrupar todas las tropas defensivas de una aldea en un mismo conjunto. - Aldea: la información de esta entidad no se ve modificada respecto de los anteriores casos de estudio. Como se puede observar en el diagrama, en una aldea sólo puede haber un conjunto de tropas defensivas que conforman, como se acaba de ver, el conjunto de defensas totales de la aldea. 63 3.7 Restricciones Hasta el momento se han definido relaciones sobre elementos tangibles dentro del universo Warbattle, lo que permitía imaginarse las relaciones existentes entre sus elementos y realizar una definición más clara y concisa. Con el tema que abarca esta sección, las restricciones, estas facilidades desaparecen, pues se definen relaciones complejas entre entidades y, en algunos casos, es difícil concretar a que entidad se ligan las relaciones del dominio. Para empezar, será útil hacer un leve recordatorio de que son las restricciones. Las restricciones definen bloqueos sobre elementos que a la vez son bloqueados por otros elementos de su mismo dominio, o de dominios diferentes. Para ilustrar el caso, se recordará un ejemplo de restricción ya vista en el capítulo 1 Estudio de la ambientación. Como se vio en ese capítulo, para poder construir infanterías ligeras, era necesario tener disponibles en la aldea: - Cuartel nivel 1. - Academia militar nivel 2. - Ataque nivel 2. En este caso, para desbloquear un tipo de unidad militar son necesarios tener dos tipos de edificio a un determinado nivel y una habilidad militar a otro. Se analizará otro caso a continuación. El elemento en estudio será la ciencia Forja del hierro. Este tipo de ciencia necesitaba tener disponibles los siguientes elementos: - Biblioteca nivel 2. Herramientas nivel 3. Para este elemento son necesarios tener disponibles un tipo de edificio a un determinado nivel y una ciencia a otro. Una vez vistos ambos casos, se puede deducir fácilmente la dificultad de definir las restricciones para los elementos, pues, a diferencia de lo que ocurría con los costes que prácticamente todas las entidades podían heredar de otra que agrupase su comportamiento, en esta ocasión cada tipo de elemento tiene características diferentes entre ellos. Para reflejar la dificultad de este caso de estudio, se observará lo siguiente: - Tanto las ciencias como las habilidades militares pertenecen a un jugador a nivel global y, por tanto, se aplican a todas las aldeas del mismo. 64 WarBattle Sin embargo, una característica intrínseca de las restricciones de éstas es que requieren de un edificio (biblioteca o academia militar según el elemento) para poder acceder a ellas o desbloquearlas. La solución que se adoptará será la de dar de alta la primera vez que se desbloquee uno de esos tipos de elementos a nivel global. Por otro lado, para acceder a ellos desde una aldea, aún a pesar de que ya pertenezcan al usuario, la misma deberá cumplir los requisitos necesarios. - El resto de elementos, edificios y unidades militares y defensivas, tienen su ciclo de vida dentro de una aldea y, por tanto, sus restricciones están sujetas a la misma. No obstante, como se vio anteriormente, todos ellos dependen de elementos globales (ciencias o habilidades militares) para ser desbloqueados. La solución a estos problemas será, además de relacionar cada restricción a su tipo de elemento bloqueado, asociar dicha restricción o bien a un jugador en caso de ser ciencia o habilidad militar, o bien a una aldea en los demás casos. Puesto que, como se ha visto a lo largo de esta sección, cada elemento tiene una configuración de restricciones distintas, serán estudiadas por separado en función del elemento restringido. 65 Ciencias y habilidades militares El siguiente diagrama muestra las relaciones y entidades participantes en este proceso: Figura 3.2.7: Diagrama 1 del modelo de dominio de las restricciones Los elementos que aparecen en el diagrama y su explicación son: - Jugador: es el elemento que tiene las ciencias y habilidades militares bloqueadas. Si se realiza la lectura de las relaciones asociadas a él, se deduce que un jugador puede tener varias ciencias o habilidades militares bloqueadas, mientras que cada una de ellas sólo puede pertenecer a un jugador. - Tipo habilidad: hace referencia al tipo de habilidad del elemento bloqueado y del elemento que puede o no desbloquearla. - Habilidad bloqueada: es la propia restricción en sí de una habilidad militar bloqueada en un momento dado. Para poder desbloquearla es necesario cumplir con los requisitos que vienen definidos bien en los atributos de la entidad como en las relaciones salientes con la entidad tipo habilidad. El significado de cada uno de ellos es el siguiente: o Nivel de la academia militar necesario para poder acceder a ella. o Un atributo que informe de la dependencia de otra habilidad para ser desbloqueada. Este atributo es “requiere habilidad”. o Nivel de la habilidad requerida en caso de que exista. 66 WarBattle o Tipo de habilidad bloqueada: aparece en la relación “bloqueada” entre tipo habilidad y habilidad bloqueada. o Tipo de habilidad desbloquea: aparece en la relación “desbloquea” entre tipo habilidad y habilidad bloqueada. - Tipo ciencia: tiene el mismo significado que la entidad tipo habilidad pero sobre los elementos de tipo de ciencias. - Ciencia bloqueada: es la propia restricción en sí de una ciencia bloqueada en un momento dado. Para poder desbloquearla es necesario cumplir con los requisitos que vienen definidos bien en los atributos de la entidad como en las relaciones salientes con la entidad tipo ciencia. El significado de cada uno de ellos es el siguiente: o Nivel de la biblioteca necesario para poder acceder a ella. o Un atributo que informe de la dependencia de otra ciencia para ser desbloqueada. Este atributo es “requiere ciencia”. o Nivel de la ciencia requerida en caso de que exista. o Tipo de ciencia bloqueada: aparece en la relación “bloqueada” entre tipo ciencia y ciencia bloqueada. o Tipo de ciencia desbloquea: aparece en la relación “desbloquea” entre tipo ciencia y ciencia bloqueada. 67 Edificios A continuación se definen las relaciones existentes en el dominio de restricciones de los edificios con el siguiente diagrama: Figura 3.2.8: Diagrama 2 del modelo de dominio de las restricciones Si se comparan este diagrama con el anterior que describía las restricciones de las habilidades militares y las ciencias, se observarán notables diferencias en la estructura de ambos. Las restricciones para este caso, han sido consideradas de forma diferente. El motivo es que si en el anterior diagrama se podía incluir como atributo la restricción por edificios debido a que sólo dependían de un tipo específico, para los edificios, es necesario agruparlo en su conjunto. Por tanto, un edificio podrá tener más de una restricción para ser desbloqueado, que podrá ser, o bien dependiente de un tipo de edificio, o bien de un tipo de ciencia. La definición de los elementos del diagrama se presenta a continuación: - Aldea: los edificios bloqueados pertenecen a una única aldea de un jugador, mientras que de otra manera las aldeas pueden tener varios edificios bloqueados en un momento dado. - Tipo edificio: tiene dos lecturas diferentes en este dominio: o Por un lado hace referencia mediante la relación “bloqueado” al tipo de edificio bloqueado en una aldea. 68 WarBattle o Por otro lado, hace referencia al tipo de edificio que puede ser el elemento que desbloquee el edificio bloqueado. Este significado se extrae de la relación “desbloquea”. - Tipo ciencia: su significado en este dominio es el de ser un posible elemento que desbloquee un tipo de edificio dado. - Edificio bloqueado: es el edificio que se encuentra bloqueado en un cierto instante en una cierta aldea. Para que pueda eliminársele el bloqueo debe de tener todas las condiciones de bloqueo, tanto de ciencias como de edificios que posea cumplidas. Para poder hacer posible esta situación, es necesario recoger la siguiente información: o Tipo de edificio bloqueado. Se extrae de la relación con tipo edificio “bloqueado”. o Tipo de elemento que desbloquea. Puede ser o bien un tipo de edificio o bien un tipo de ciencia. o Nivel del elemento al que desbloquea. 69 Unidades militares y defensivas Los últimos elementos del dominio que van a ser estudiados son las restricciones de las unidades militares y defensivas. Estos tipos de elementos funcionan de la siguiente manera: - En el caso de las unidades militares, las restricciones dependen de tres factores: o Nivel del cuartel necesario para construir el tipo de unidad militar deseado. o Nivel de la academia militar requerido para desbloquear el tipo de unidad militar deseado. o Tipo de habilidad militar que desbloquea el tipo de unidad militar deseada. - En el caso de las unidades defensivas, las restricciones dependen de otros tres factores: o Nivel del taller militar necesario para construir el tipo de unidad defensiva deseado. o Nivel de la academia militar requerido para desbloquear el tipo de unidad defensiva deseado. o Tipo de habilidad militar que desbloquea el tipo de unidad defensiva deseada. Por otro lado, las restricciones de ambos tipos de unidades, tanto militares como defensivas, van asociadas a una única aldea, por lo que cada aldea tendrá sus propias unidades bloqueadas. Toda esta información viene reflejada en el siguiente diagrama: 70 WarBattle Figura 3.2.9: Diagrama 3 del modelo de dominio de las restricciones Las entidades y relaciones reflejadas en el dominio del diagrama son las siguientes: - Aldea: es el lugar donde tienen cabida los bloqueos tanto de las unidades militares como de las unidades defensivas. Cada aldea tendrá sus propios bloqueos en función del grado de avance de la misma. - Tipo habilidad: en este dominio actúa como elemento que desbloquea tanto las unidades militares como las defensivas tal y como puede observarse en la relación con unidad bloqueada “desbloquea”. - Tipo unidad: es el tipo de unidad militar bloqueada en una aldea específica en un instante dado tal y como puede apreciarse en la relación “bloqueada” con unidad bloqueada. - Unidad bloqueada: esta entidad recoge la información necesaria para conocer los requisitos necesarios para que una unidad militar sea desbloqueada. - Tipo defensa: es el tipo de unidad defensiva bloqueada en una aldea específica en un instante dado tal y como puede apreciarse en la relación “bloqueada” con defensa bloqueada. 71 - Defensa bloqueada: esta entidad recoge la información necesaria para conocer los requisitos necesarios para que una unidad defensiva sea desbloqueada. 72 WarBattle 3.8 Misiones En esta sección se va a realizar el estudio de uno de los aspectos más críticos del sistema, las misiones. Hasta el momento, al realizar el estudio de los elementos anteriores, no se ha hecho ninguna mención al tiempo entre eventos. La criticidad de este dominio radica, básicamente, en dos aspectos fundamentales: - Recientemente se ha hecho una pequeña introducción al concepto de tiempo entre eventos. Este hecho significa que al ser un juego en tiempo real, con múltiples jugadores interaccionando entre sí y accediendo simultáneamente a recursos compartidos, no sólo mediante lectura, sino también mediante escritura, el sistema debe gestionar correctamente la variable del tiempo. En el dominio de las misiones es, si cabe, más importante realizar perfectamente esta gestión. Para ilustrar mejor este proceso se utilizará un ejemplo sencillo. Imaginemos tres jugadores A, B y C. El jugador A ataca a B, llegando su ataque a las 21:00 del sistema. Por otro lado, el jugador C también ataca a B, pero su ataque es anterior y llega a las 20:59. Si se tiene en cuenta que el sistema actualiza las cuentas de los jugadores cuando uno de ellos genera algún evento (que es el procedimiento que va a utilizar el sistema), podríamos encontrarnos con el siguiente problema: C tiene previsto el ataque sobre B antes que A, pero ninguno de los tres genera un evento antes de las 21:00. Hasta entonces no habría ningún problema, pues el sistema simplemente se queda a la espera de actualizar según le lleguen eventos. Pero a las 21:05 llega el primer evento de los tres jugadores, que es el del jugador A. En este momento el sistema debería actualizar todos los elementos actualizables del jugador A, atacando en teoría, antes que C y generando una situación imposible. La figura siguiente ilustra el ejemplo mencionado: Figura 3.2.10: Ejemplo de sucesos en el tiempo 73 Como se ha analizado en el ejemplo expuesto, el tiempo es una variable crítica que debe ser tratada con muchísimo cuidado. Más adelante, durante la fase de diseño se procederá a realizar un estudio mucho mayor sobre los elementos de actualización y se explicará en detalle la solución empleada. - Ya se ha visto por encima en el ejemplo utilizado en el anterior epígrafe que he un elemento importantísimo y de criticidad muy elevada es la concurrencia de eventos de diferentes jugadores sobre un mismo recurso, sobre todo cuando éste va a ser utilizado sobre operaciones de escritura. Antes de confeccionar el modelo de dominio, es necesario explicar un par de conceptos más. Las misiones consisten en enviar tropas desde un punto a otro para realizar alguna tarea determinada. Este hecho implica que las misiones tienen un punto de partida y otro de destino. En el juego, este suceso se ve reflejado en que las misiones parten de unas coordenadas de origen a otras de destino. Por otro lado, recordemos que había cuatro tipos de misiones: - Transporte. Combate. Espionaje. Colonización. Una explicación más amplia se puede obtener en el capítulo 1 Estudio de la ambientación. Para realizar el dominio, nos interesa observar un concepto fundamental de los distintos tipos de misiones. Las tres primeras son misiones de ida y vuelta, es decir, una vez llegado al destino y ejercer su cometido, deben volver a las coordenadas de origen. La misión colonización, si ha tenido éxito, al llegar a su destino desaparece, cumpliendo su cometido y creando un nuevo castillo. Por otro lado, después de un ataque también puede darse el caso de que las tropas que atacaban pierdan el combate, en cuyo caso la misión también desaparecerá de una forma similar a como desaparecen las colonizaciones que tienen éxito. Una vez explicados los conceptos relativos a las misiones, sus problemas y sus tipos, a continuación se presenta el modelo de dominio alcanzado para este caso: 74 WarBattle Figura 3.2.11: Diagrama del modelo de dominio de las misiones Los elementos que intervienen en el diagrama son los siguientes: - Casilla: este nuevo elemento no visto hasta ahora representa una casilla en el mapa. De momento no se va a abordar su definición y características, sino que su misión en este diagrama es representar la casilla de destino de la misión, que puede estar o no ocupada por otro jugador. En el punto 2.10 Sistema de coordenadas se profundizará en su descripción. - Aldea: representa la aldea desde la que parte la misión y que será, a su vez, la de destino cuando la misión alcance su destino original y esté de regreso. - Misión: esta entidad incluye la información específica sobre una misión en particular. Recoge información de tipo temporal, como las horas de inicio, llegada y vuelta, como del tipo de misión que llevará o llevó a cabo. Como se puede ver en las relaciones salientes, esta entidad tiene las siguientes características: o Su destino sólo puede ser una casilla del mapa. o Su origen sólo puede ser una aldea del jugador que envía la misión. o Cada misión pertenece a un sólo jugador, no obstante, cada jugador puede tener múltiples misiones simultáneas. o Una misión está formada por un ejército que sólo puede tomar parte en una misión. - Jugador: representa el jugador que envía la misión. - Ejército: representa el ejército que lleva a cabo la misión. 75 3.9 Elementos en construcción En esta sección se realizará el estudio de aquéllos elementos del juego que pueden ser construidos (a excepción de los castillos que tienen un significado completamente diferente al resto), así como de dónde y cuándo tiene lugar su construcción y de los requisitos necesarios para que se produzca la misma. Los elementos construibles son: - Productores. - Edificios. - Ciencias. - Habilidades militares. - Unidades militares. - Unidades defensivas. Todos ellos tienen una característica en común, que es que todos tienen un tiempo de finalización en su construcción. Sin embargo, también existen una serie de diferencias entre ellos. Estas diferencias vienen determinadas por el tipo de elemento a construir. A continuación se van a ir explicando estas diferencias. Los productores y los edificios tienen un funcionamiento idéntico. Ambas construcciones tienen lugar en una aldea y sólo en ella. Ninguno de ellos puede ponerse a construir si ya existe otro elemento del mismo tipo en construcción. Es decir, si en el momento en el que existe un edificio construyéndose en una aldea se quisiera poner en construcción otro, el sistema debería impedírselo al usuario. De igual modo sucedería entre productores. Por otro lado se encuentran las ciencias y habilidades militares, cuya estrategia es prácticamente similar. Al igual que sucedía con productores y edificios, no se pueden poner a investigar ninguna de las dos si hay otro elemento del mismo tipo investigándose, no al menos hasta que dicha investigación se haya llevado a cabo. Sin embargo, a diferencia de lo que ocurría con los edificios y productores, para estos dos tipos de elementos existe un fenómeno nuevo. Una ciencia no podrá ser investigada si en alguna aldea del jugador existe alguna biblioteca en construcción. De igual modo, ninguna habilidad militar podrá ser desarrollada mientras haya alguna academia militar construyéndose en alguna aldea del mismo jugador. 76 WarBattle La lectura en sentido contrario se realiza de forma muy similar. Un jugador, sea en la aldea que sea bajo su poder, no podrá poner a construir una biblioteca mientras esté investigando una ciencia. Igualmente sucede con las academias militares y las habilidades militares. Las unidades militares y unidades defensivas, por otro lado, también siguen una estrategia idéntica durante su construcción, aunque completamente distinta del resto de elementos vistos hasta el momento. En el caso de estos dos tipos de unidades de combate, hay que tener en cuenta que no se construye un único ítem de ellos como con los demás, sino que se ponen unidades de un determinado tipo de unidad. Por tanto, el sistema deberá ser capaz de mantener la información de cuantas unidades se han puesto a construir de un determinado tipo de unidad de combate y a qué hora acaba cada una de construirse para su actualización. Puesto que intervienen demasiados elementos para ser expresados de forma cómoda en un diagrama, se dividirán por conjuntos. 77 Productores y edificios El siguiente diagrama muestra las entidades y relaciones de este dominio: Figura 3.2.12: Diagrama 1 del modelo de dominio de las construcciones La descripción de los elementos que intervienen en el dominio es: - Aldea: ambos tipos de construcciones, las de los edificios y las de los productores, se llevan a cabo, como se ha visto a lo largo de esta sección, dentro de las aldeas. Como se puede observar en el diagrama adjunto, esta entidad ha adquirido un nuevo atributo. Éste es la última hora de consulta, que recoge la hora en la que el usuario o el sistema realizaron el último evento sobre la aldea, después de un proceso de actualización de la misma. Con esa hora y con las que se verán a continuación con las entidades productor pendiente y edificio pendiente, se calculará la finalización o no de ese tipo de elementos. - Productor pendiente: es el productor en construcción. Hace referencia al productor que se está construyendo de la aldea en la que se encuentra este último, tal y como se puede observar en la relación [1, 0,1] entre ellas. Su atributo hora de construcción indica la hora en que el productor en construcción terminara la misma. - Productor: hace referencia al productor en cuestión que está siendo construido en un momento dado en una aldea. - Edificio pendiente: es el edificio en construcción. Hace referencia al edificio que se está construyendo de la aldea en la que se 78 WarBattle encuentra este último, tal y como se puede observar en la relación [1, 0,1] entre ellas. Su atributo hora de construcción indica la hora en que el edificio en construcción terminara la misma. - Edificio: hace referencia al edificio en cuestión que está siendo construido en un momento dado en una aldea. 79 Ciencias y habilidades militares El siguiente diagrama muestra las entidades y relacionadas con el dominio que va a ser estudiado: Figura 3.2.13: Diagrama 2 del modelo de dominio de las construcciones Las entidades y relaciones mostradas en el diagrama son: - Jugador: hace referencia al jugador que tiene ciencias o habilidades investigándose. - Ciencia: es la referencia a la ciencia que está siendo investigada. - Ciencia pendiente: reúne la información necesaria para saber: o El usuario al que pertenece la ciencia en investigación. Recordemos que el usuario sólo puede tener una ciencia en ese estado. o La ciencia que está siendo investigada. o La hora de finalización en la investigación. - Habilidad: es la referencia a la habilidad que está siendo desarrollada. 80 Habilidad pendiente: reúne la información necesaria para saber: WarBattle o El usuario al que pertenece la habilidad en desarrollo. Recordemos que el usuario sólo puede tener una habilidad en ese estado. o La habilidad que está siendo desarrollada. o La hora de finalización en el desarrollo. - Aldea: es la aldea en la que se está construyendo o la academia militar o la biblioteca. - Biblioteca pendiente: es la biblioteca que está siendo construida en una aldea en un momento dado y que determina si una ciencia puede ser investigada o no. De la relación con aldea, se puede deducir que un usuario puede tener varias bibliotecas construyéndose. - Academia pendiente: es la academia militar que está siendo construida en una aldea en un momento dado y que determina si una habilidad militar puede ser desarrollada o no. De la relación con aldea, se puede deducir que un usuario puede tener varias academias militares construyéndose. - Edificio pendiente: es la referencia de la academia o biblioteca que se está construyendo. 81 Unidades militares y defensivas El siguiente diagrama muestra las entidades y relacionadas con el dominio que va a ser estudiado: Figura 3.2.14: Diagrama 3 del modelo de dominio de las construcciones Las entidades y relaciones mostradas en el diagrama son: - Aldea: es el lugar donde se lleva a cabo la construcción de unidades militares y defensivas. - Defensa disponible: informa al sistema de los tipos de defensa que ya han sido desbloqueados y que, por tanto, ya pueden ser construidos (siempre y cuando se cumplan los requisitos de costes). - Tipo defensa: es el tipo de defensa que o bien ya está disponible o bien está siendo construida, en función de la lectura que se haga de sus dos relaciones. - Defensa pendiente: es el conjunto de unidades de un mismo tipo de unidad defensiva que están siendo construidas en una aldea en un instante concreto. Sus atributos son, por tanto: o Hora de construcción de una unidad de un tipo de unidad defensiva. 82 WarBattle o Número construcción. de unidades defensivas pendientes de - Unidad disponible: informa al sistema de los tipos de unidades que ya han sido desbloqueados y que, por tanto, ya pueden ser construidos (siempre y cuando se cumplan los requisitos de costes). - Tipo unidad: es el tipo de unidad que o bien ya está disponible o bien está siendo construida, en función de la lectura que se haga de sus dos relaciones. - Unidad pendiente: es el conjunto de unidades de un mismo tipo de unidad militar que están siendo construidas en una aldea en un instante concreto. Sus atributos son, por tanto: o Hora de construcción de una unidad de un tipo de unidad militar. o Número de unidades militares pendientes de construcción. 83 3.10 Sistema de coordenadas En esta sección se realizará el estudio del dominio relativo al sistema de coordenadas. Como ya se explicó en el capítulo 1 Estudio de la ambientación, el mapa está organizado en 16 tierras, que a su vez están cada una de ellas organizada en 49 sectores y que, por último, se encuentran divididas en 16 posiciones. De estas tres distinciones geográficas, se deduce que las casillas de juego están constituidas por el siguiente formato: [Tierra : Sector : Posición]. Una vez definido el sistema de coordenadas, es momento de especificar el uso de las casillas del mapa. En las casillas van alojadas las aldeas de los usuarios. Una aldea sólo podrá estar situada en una casilla, que será siempre la misma. Por su parte, cada casilla sólo podrá contener una aldea, que será, también, siempre la misma. Por último, el sistema asignará de forma pseudoaleatoria el tipo de terreno que definirá en última instancia la casilla utilizando un sistema de equilibrio que se verá más adelante a la hora de realizar el diseño. Los tipos de terreno del universo Warbattle son: - Llanura. - Bosque. - Monte. El siguiente diagrama muestra las entidades y relaciones pertenecientes al dominio: 84 WarBattle Figura 3.2.15: Diagrama del modelo de dominio del sistema de coordenadas Las entidades y relaciones mostradas en el diagrama son: - Aldea: es elemento que ocupa las casillas del mapa. - Casilla: esta entidad se corresponde con cada una de las posiciones del mapa que constituyen los puntos de juego posibles. Los atributos que conforman esta entidad son: o Tierra en la que está situada la casilla. o Sector en el que está situada la casilla. o Posición que ocupa en el sector. o Tipo de terreno que puede ser llanura, bosque o monte. 85 Análisis de los casos de uso 4. El tema de estudio que será tratado en este capítulo es el análisis de los casos de uso. Una vez realizado el modelo de dominio, ya se ha extraído y modelado la información suficiente para conocer el entorno y los elementos que formarán parte del juego Warbattle. El análisis de los casos de uso es una herramienta fundamental en los procesos de ingeniería del software hoy en día. Es una técnica para la captura de requisitos funcionales del sistema. Otra posible definición puede ser la de que un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Un caso de uso, por tanto, responde a un objetivo de un actor respecto al sistema. El modelo de casos de uso se está formado por dos componentes: Diagrama de casos de uso. Descripción detallada de cada caso de uso. Una vez vista la definición y sentido del análisis de casos de uso, se procederá a definir los límites del mismo sobre el sistema que va a ser estudiado, en este caso, el juego Warbattle. Para proporcionar una lectura fácil y cómoda al lector se evitará realizar un único diagrama de magnitudes enormes y de contenido farragoso. La solución empleada será la de elaborar diagramas y descripciones separadas en grupos cuyos contenidos tengan una relación directa entre sí. Los grupos en que se dividirá el análisis son: Acceso al sistema. Acciones informativas. Acciones sobre la producción. Acciones sobre los edificios. Acciones sobre unidades militares. Acciones sobre unidades defensivas. Acciones sobre las ciencias. Acciones sobre las habilidades militares. Acciones sobre el mapa. Acciones sobre misiones. 86 WarBattle 4.1 Acceso al sistema Las funciones descritas en este apartado tienen que ver con aquellas que sirvan para que el usuario tenga acceso al juego, ya sea accediendo al mismo si ya es un jugador registrado, ya sea registrándose por primera vez en el juego y accediendo al mismo posteriormente. Estas funciones aparecen recogidas en el siguiente diagrama: Registrar jugador Jugador Acceder al juego Figura 3.3.1: Diagrama de casos de uso de acceso al sistema Antes de proceder a la descripción detallada de cada caso de uso, es fundamental resaltar que ambas unidades funcionales se realizan sobre la página principal del juego. 87 Caso de uso 1: Registrar jugador El usuario al acceder a la página de inicio selecciona la opción registro. Figura 3.3.2: Página principal Una vez seleccionada la opción, se encontrará con la siguiente vista: Figura 3.3.3: Página de registro 88 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones - Escenario primario 1. El usuario introduce los datos de usuario y acepta los términos y condiciones de uso. 2. El sistema verifica la validez y disponibilidad de los datos introducidos, registra al jugador, le asigna una nueva cuenta y le concede acceso al juego. Extensiones 2a. Los datos de usuario son incorrectos. 1. El sistema muestra una página de error en la autenticación. 2b. Los datos de usuario ya están dados de alta en el sistema. 1. El sistema muestra una página de error en la autenticación. Descripción de datos Datos de usuario 1. Nombre en el juego. 2. Contraseña. 3. Dirección de correo electrónico. 89 Caso de uso 2: Acceder al juego El usuario al acceder a la página de inicio accede al juego. Figura 3.3.4: Página principal Para acceder debe introducir los datos en el siguiente formulario: Figura 3.3.5: Formulario de acceso 90 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones - Escenario primario 1. El usuario introduce su identificación. 2. El sistema comprueba que el jugador está registrado y le concede acceso al juego. Extensiones 2a. La identificación es incorrecta. 2. El sistema muestra una página de error en la autenticación. Descripción de datos Identificación 1. Nombre en el juego. 2. Contraseña. 91 4.2 Acciones informativas En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema con carácter informativo sobre las aldeas y los mensajes de un jugador. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver información aldea Cambiar aldea Ver mensajes Jugador Ampliar información mensaje Borrar mensaje Figura 3.3.6: Diagrama de casos de uso de acciones informativas Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 92 WarBattle Caso de uso 3: Ver información de la aldea en la que se encuentre el jugador El jugador elige sobre el panel de opciones de la izquierda la opción “Inicio”. Figura 3.3.7: Vista general del juego Opción inicio: Figura 3.3.8: Opción inicio 93 94 Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario elige la opción inicio. 2. El sistema extrae de la sesión la aldea que estaba siendo consultada y devuelve al navegador la vista deseada. Extensiones - Descripción de datos - WarBattle Caso de uso 4: Cambiar aldea El jugador elige sobre el panel de aldeas de la parte superior izquierda una de las aldeas que tiene bajo su mando. Figura 3.3.9: Vista general del juego Para elegir cambiar de aldea, el jugador debe elegir una aldea diferente de la lista desplegable situada en el panel de aldeas mostrado en la figura siguiente: Figura 3.3.10: Panel de aldeas 95 96 Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona una de las aldeas disponibles. 2. El sistema extrae de la request la aldea a la que se desea acceder, la sustituye por la anterior en la sesión y prepara la vista para el navegador. Extensiones 1a. El usuario elige la aldea en la que ya se encontraba. 1. No se genera request y, por tanto, el sistema no interviene en el proceso. Descripción de datos - WarBattle Caso de uso 5: Ver mensajes El jugador elige sobre el panel de opciones de la parte superior la opción “Mensajes”. Figura 3.3.11: Vista general del juego Se genera la siguiente vista donde aparecen los mensajes que tiene un usuario en el momento del envío del evento. Figura 3.3.12: Panel de información sobre misiones 97 98 Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario elige la opción mensajes. 2. El sistema extrae los mensajes almacenados y vigentes del jugador que realiza la petición, prepara la vista y la envía al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 6: Ampliar información de los mensajes El jugador, una vez ha elegido la opción de los mensajes, selecciona ver más información sobre uno de ellos. Figura 3.3.13: Panel de información sobre las misiones Para ver más información sobre un mensaje, el jugador deberá pinchar sobre el siguiente icono adjunto a determinados tipos de mensaje. Figura 3.3.14: Vista ampliada del botón ver un mensaje 99 100 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción mensajes. 3. Existe algún mensaje con la opción de ampliar información. Escenario primario 1. El usuario elige la opción ampliar información de un mensaje. 2. El sistema extrae el mensaje seleccionado y muestra en el navegador la información relativa al mensaje. Extensiones - Descripción de datos - WarBattle Caso de uso 7: Borrar mensaje El jugador, una vez ha elegido la opción de los mensajes, selecciona la opción borrar el mensaje sobre uno de ellos. Figura 3.3.15: Panel de información sobre las misiones Para borrar un mensaje, el jugador deberá pinchar sobre el siguiente icono adjunto a cualquier mensaje. Figura 3.3.16: Vista ampliada del botón borrar mensaje 101 102 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción mensajes. Escenario primario 1. El usuario elige la opción borrar mensaje. 2. El sistema extrae el mensaje seleccionado y lo da de baja en sí mismo. A continuación muestra la página general de información de la aldea en la que se encuentra el jugador. Extensiones - Descripción de datos - WarBattle 4.3 Acciones sobre la producción En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto a la producción y los elementos que intervienen en este proceso en las aldeas. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver producción de una aldea Ver productor Jugador Aumentar de nivel un productor Figura 3.3.17: Diagrama de casos de uso de acciones sobre la producción Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 103 Caso de uso 8: Ver producción de una aldea El jugador elige la opción “Producción” en el panel de opciones del margen izquierdo del interfaz. Figura 3.3.18: Vista general del juego Opción Producción: Figura 3.3.19: Botón producción 104 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El jugador elige la opción producción. 2. El sistema extrae de la sesión la aldea seleccionada y prepara la información relativa al sistema de producción en esa aldea para que la muestre el navegador del jugador. Extensiones - Descripción de datos - 105 Caso de uso 9: Ver productor El jugador, una vez ha elegido la opción “Producción” del panel de opciones del margen izquierdo, selecciona sobre cualquier casilla del mapa de productores para ver más información al respecto. Figura 3.3.20: Panel de información sobre la producción Al seleccionar cualquiera de las casillas de productores, el sistema debe devolver la siguiente vista con información sobre el productor seleccionado. Figura 3.3.21: Vista de un productor seleccionado 106 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción producción. Escenario primario 1. El usuario selecciona cualquier productor del tablero de productores. 2. El sistema extrae el productor seleccionado, realiza una lectura de la información de éste y la devuelve al usuario. Extensiones 2a. El jugador no tiene en la aldea recursos suficientes para aumentar el nivel del productor. 1. El sistema prepara la vista sin habilitar la opción de aumento de nivel. Descripción de datos Recursos 1. Tipo de recurso. 2. Unidades del recurso. 107 Caso de uso 10: Aumentar de nivel un productor El jugador, una vez ha seleccionado un productor, elige la opción “Aumentar nivel” del productor escogido. Figura 3.3.22: Vista ampliada de un productor Para aumentar de nivel el productor seleccionado debe estar habilitada la opción “Aumentar nivel” y pinchar sobre ella. Figura 3.3.23: Vista ampliada de la opción “Aumentar nivel” 108 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción producción. 3. El jugador debe haber elegido ver la información de un productor. 4. La opción de aumento de nivel debe estar habilitada. Escenario primario 1. El usuario elige la opción aumentar nivel. 2. El sistema realiza la lectura del productor que se quiere aumentar de nivel y procede a realizar los cálculos y escrituras pertinentes sobre el proceso. Una vez realizados, prepara la vista de información general de la aldea y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 109 4.4 Acciones sobre los edificios En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto a los edificios de las aldeas y la información y opciones que debe mostrar en función de la petición del usuario. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver edificios Ver información de un edificio Aumentar de nivel un edificio Acceder a la biblioteca Jugador Acceder a la academia militar Acceder al cuartel Acceder al taller de defensa Figura 3.3.24: Diagrama de casos de uso de acciones sobre los edificios Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 110 WarBattle Caso de uso 11: Ver edificios El jugador elige la opción “Edificios” del panel de opciones del margen izquierdo del interfaz de juego. Figura 3.3.25: Interfaz del juego Opción edificios: Figura 3.3.26: Botón edificios 111 112 Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona la opción ver edificios. 2. El sistema extrae de la sesión la aldea en la que se encuentra el jugador y realiza la lectura de los edificios que tiene la aldea. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - WarBattle Caso de uso 12: Ver información de un edificio El jugador, una vez ha elegido la opción “Edificios” del panel de opciones del margen izquierdo, selecciona sobre cualquier edificio para ver más información al respecto. Figura 3.3.27: Panel de información sobre los edificios Al seleccionar cualquiera de los edificios, el sistema debe devolver la siguiente vista con información sobre el edificio seleccionado. Figura 3.3.28: Vista de la información de un edificio ampliada 113 114 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción edificios. Escenario primario 1. El usuario selecciona cualquier edificio del tablero de edificios. 2. El sistema extrae el edificio seleccionado, realiza una lectura de la información de éste y la devuelve al usuario. Extensiones 2a. El jugador no tiene en la aldea recursos suficientes para aumentar el nivel del edificio. 1. El sistema prepara la vista sin habilitar la opción de aumento de nivel. Descripción de datos Recursos 1. Tipo de recurso. 2. Unidades del recurso. WarBattle Caso de uso 13: Aumentar de nivel un edificio El jugador, una vez ha seleccionado un edificio, elige la opción “Aumentar nivel” del edificio escogido. Figura 3.3.29: Vista de la información de un edificio ampliada Para aumentar de nivel el edificio seleccionado debe estar habilitada la opción “Aumentar nivel” y pinchar sobre ella. Figura 3.3.30: Vista ampliada de la opción “Aumentar nivel” de un edificio 115 116 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción edificios. 3. El jugador debe haber elegido ver la información de un edificio. 4. La opción de aumento de nivel debe estar habilitada. Escenario primario 1. El usuario elige la opción aumentar nivel. 2. El sistema realiza la lectura del edificio que se quiere aumentar de nivel y procede a realizar los cálculos y escrituras pertinentes sobre el proceso. Una vez realizados, prepara la vista de información general de la aldea y la devuelve al navegador del jugador. Extensiones - Descripción de datos - WarBattle Caso de uso 14: Acceder a la biblioteca El jugador había elegido la opción ver biblioteca y selecciona la opción “Acceder” en ella. Figura 3.3.31: Vista de la información de una biblioteca ampliada Para entrar a ver las ciencias disponibles en la biblioteca seleccionada, hay que pulsar sobre la opción “Acceder”. Figura 3.3.32: Vista ampliada de la opción “Acceder” de una biblioteca 117 118 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción edificios. 3. El jugador debe haber elegido ver la información de la biblioteca. Escenario primario 1. El usuario elige la opción acceder a la biblioteca. 2. El sistema realiza la lectura de la biblioteca seleccionada y prepara la vista con las ciencias disponibles para esa biblioteca y la devuelve al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 15: Acceder a la academia militar El jugador había elegido la opción ver academia militar y selecciona la opción “Acceder” en ella. Figura 3.3.33: Vista de la información de una academia militar ampliada Para entrar a ver las habilidades militares disponibles en la academia militar seleccionada, hay que pulsar sobre la opción “Acceder”. Figura 3.3.34: Vista ampliada de la opción “Acceder” de una academia militar 119 120 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción edificios. 3. El jugador debe haber elegido ver la información de la academia militar. Escenario primario 1. El usuario elige la opción acceder a la academia militar. 2. El sistema realiza la lectura de la academia militar seleccionada y prepara la vista con las habilidades militares disponibles para esa academia militar y la devuelve al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 16: Acceder al cuartel El jugador había elegido la opción ver cuartel y selecciona la opción “Acceder” en ella. Figura 3.3.35: Vista de la información de un cuartel ampliada Para entrar a ver las unidades militares disponibles en el cuartel seleccionado, hay que pulsar sobre la opción “Acceder”. Figura 3.36: Vista ampliada de la opción “Acceder” de un cuartel 121 122 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción edificios. 3. El jugador debe haber elegido ver la información del cuartel. Escenario primario 1. El usuario elige la opción acceder al cuartel. 2. El sistema realiza la lectura del cuartel seleccionado y prepara la vista con las unidades militares disponibles para ese cuartel y la devuelve al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 17: Acceder al taller de defensa El jugador había elegido la opción ver taller de defensa y selecciona la opción “Acceder” en él. Figura 3.3.37: Vista de la información de un taller de defensa ampliada Para entrar a ver las unidades defensivas disponibles en el taller defensivo seleccionado, hay que pulsar sobre la opción “Acceder”. Figura 3.3.38: Vista ampliada de la opción “Acceder” de un taller de defensa 123 124 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción edificios. 3. El jugador debe haber elegido ver la información del taller de defensa. Escenario primario 1. El usuario elige la opción acceder al taller de defensa. 2. El sistema realiza la lectura del taller de defensa seleccionado y prepara la vista con las unidades defensivas disponibles para ese taller de defensa y la devuelve al navegador. Extensiones - Descripción de datos - WarBattle 4.5 Acciones sobre unidades militares En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto a las unidades militares. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver información de una unidad militar Construir unidades militares Jugador Ver unidades militares disponibles Figura 3.3.39: Diagrama de casos de uso de acciones sobre unidades militares Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 125 Caso de uso 18: Ver información de una unidad militar El jugador eligió la opción ver cuartel dentro de los edificios. El sistema le muestra las unidades militares que puede construir en esa aldea. Una vez presentada la información, el jugador pulsa sobre cualquier unidad para ver toda la información relativa a ella. Figura 3.3.40: Unidades disponibles en un cuartel Al pulsar sobre cualquier imagen de una unidad se mostrará la información relativa a ésta. Figura 3.3.41: Información sobre la unidad elegida 126 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador ha tenido que elegir la opción edificios. 3. El jugador ha elegido la opción ver cuartel. 4. El jugador tiene unidades militares disponibles para mostrar en esa aldea. Escenario primario 1. El usuario pulsa sobre la imagen de un tipo de unidad. 2. El sistema realiza la lectura de la unidad seleccionada y prepara la vista con la información de ésta para devolverla al navegador. Extensiones - Descripción de datos - 127 Caso de uso 19: Construir unidades militares El jugador debe venir del caso de uso 17 Ver cuartel. A continuación introduce el número de unidades que quiere construir de cada tipo de unidad militar que tenga disponible en la aldea y selecciona la opción construir (también puede utilizar la tecla Enter). Figura 3.3.42: Vista del cuartel Una vez introducidas el número de unidades que desea, selecciona construir. Figura 3.3.43: Opción “Continuar” 128 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador ha tenido que elegir la opción edificios. 3. El jugador ha elegido la opción ver cuartel. 4. El jugador tiene unidades militares disponibles para mostrar en esa aldea. Escenario primario 1. El usuario introduce el número de unidades que quiere construir de cada tipo de unidad militar. 2. El sistema construye todas las unidades permitidas dependiendo del número de recursos y prepara la vista general de la aldea para devolverla al navegador. Extensiones - Descripción de datos - 129 Caso de uso 20: Ver unidades militares disponibles El jugador elige la opción “Tropas” del panel de opciones del margen izquierdo del interfaz de juego. Figura 3.3.44: Interfaz del juego Opción tropas: Figura 3.3.45: Botón tropas 130 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona la opción ver tropas. 2. El sistema extrae de la sesión la aldea en la que se encuentra el jugador y realiza la lectura de las unidades militares estacionadas en la aldea. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 131 4.6 Acciones sobre unidades defensivas En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto a las unidades defensivas. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver información de una unidad defensiva Construir unidades defensivas Jugador Ver unidades defensivas disponibles Figura 3.3.46: Diagrama de casos de uso de acciones sobre unidades defensivas Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 132 WarBattle Caso de uso 21: Ver información de una unidad defensiva El jugador eligió la opción ver taller de defensa dentro de los edificios. El sistema le muestra las unidades defensivas que puede construir en esa aldea. Una vez presentada la información, el jugador pulsa sobre cualquier unidad para ver toda la información relativa a ella. Figura 3.3.47: Vista del taller de defensa Al pulsar sobre cualquier imagen de una unidad defensiva se mostrará la información relativa a ésta. Figura 3.3.48: Información sobre la unidad defensiva seleccionada 133 134 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador ha tenido que elegir la opción edificios. 3. El jugador ha elegido la opción ver taller de defensa. 4. El jugador tiene unidades defensivas disponibles para mostrar en esa aldea. Escenario primario 1. El usuario pulsa sobre la imagen de un tipo de unidad defensiva. 2. El sistema realiza la lectura de la unidad seleccionada y prepara la vista con la información de ésta para devolverla al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 22: Construir unidades defensivas El jugador debe venir del caso de uso 18 Ver taller de defensa. A continuación introduce el número de unidades que quiere construir de cada tipo de unidad defensiva que tenga disponible en la aldea y selecciona la opción construir (también puede utilizar la tecla Enter). Figura 3.3.49: Vista del taller de defensa Una vez introducidas el número de unidades que desea, selecciona construir. Figura 3.3.50: Vista ampliada de la opción “Continuar” 135 136 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador ha tenido que elegir la opción edificios. 3. El jugador ha elegido la opción ver taller de defensa. 4. El jugador tiene unidades defensivas disponibles para mostrar en esa aldea. Escenario primario 1. El usuario introduce el número de unidades que quiere construir de cada tipo de unidad defensiva. 2. El sistema construye todas las unidades permitidas dependiendo del número de recursos y prepara la vista general de la aldea para devolverla al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 23: Ver unidades defensivas disponibles El jugador elige la opción “Defensa” del panel de opciones del margen izquierdo del interfaz de juego. Figura 3.3.51: Interfaz del juego Opción defensa: Figura 3.3.52: Opción defensa 137 138 Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona la opción ver defensas. 2. El sistema extrae de la sesión la aldea en la que se encuentra el jugador y realiza la lectura de las unidades defensivas de la aldea. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - WarBattle 4.7 Acciones sobre las ciencias En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto a las ciencias. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver ciencias del jugador Ver información sobre una ciencia Jugador Aumentar de nivel una ciencia Figura 3.3.53: Diagrama de casos de uso de acciones sobre las ciencias Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 139 Caso de uso 24: Ver ciencias del jugador El jugador elige la opción “Ciencia” del panel de opciones del margen superior del interfaz de juego. Figura 3.3.52: Interfaz del juego Opción ciencia: Figura 3.3.53: Opción ciencia 140 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona la opción ver ciencias. 2. El sistema realiza la lectura de las ciencias que posee el jugador. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 141 Caso de uso 25: Ver información sobre una ciencia Este caso de uso puede provenir de dos diferentes casos de uso, tanto del caso de uso 24 Ver ciencias como del caso de uso 14 Acceder a la biblioteca. La diferencia que existirá entre uno y otro será el número de ciencias a mostrar y la opción de que puede aumentarse de nivel que estará bloqueada si proviene del caso de uso 24 Ver ciencias. En cualquier caso en ambas situaciones al pulsar sobre cualquier ciencia aparecerá la información relativa a ésta. En ambos casos también el formato del interfaz antes de seleccionar la ciencia de la que se quiere adquirir información será el siguiente: Figura 3.3.54: Vista común de la opción ciencias y de la biblioteca 142 WarBattle Al pulsar sobre cualquier imagen de una ciencia estando en la biblioteca se mostrará la siguiente información Figura 3.3.55: Interfaz de la biblioteca Al pulsar sobre cualquier imagen de una ciencia al seleccionar la opción ciencia se mostrará la siguiente información: Figura 3.3.56: Interfaz de ciencias Como se puede observar, las diferencias entre un formato y otro residen, básicamente en la incorporación de información sobre el coste de investigación y el proceso de aumento de ésta. 143 144 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2a. El jugador ha tenido que elegir la opción ciencia. 2b. El jugador ha tenido que elegir la opción acceder a la biblioteca. 3. El jugador tiene ciencias que mostrar. Escenario primario 1. El usuario pulsa sobre la imagen de un tipo de ciencia. 2. El sistema realiza la lectura de la ciencia seleccionada y prepara la vista con la información de ésta para devolverla al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 26: Aumentar de nivel una ciencia El jugador, una vez ha seleccionado una ciencia y viniendo del caso de uso 14 Acceder a la biblioteca, elige la opción “Aumentar nivel” de la ciencia escogida. Figura 3.3.57: Información sobre una ciencia seleccionada Para aumentar de nivel la ciencia seleccionada debe estar habilitada la opción “Aumentar nivel” y pinchar sobre ella. Figura 3.3.58: Vista ampliada de la opción “Aumentar nivel” de una ciencia 145 146 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción ver la biblioteca. 3. El jugador debe haber elegido ver la información de una ciencia. 4. La opción de aumento de nivel debe estar habilitada. Escenario primario 1. El usuario elige la opción aumentar nivel. 2. El sistema realiza la lectura de la ciencia que se quiere aumentar de nivel y procede a realizar los cálculos y escrituras pertinentes sobre el proceso. Una vez realizados, prepara la vista de información general de la aldea y la devuelve al navegador del jugador. Extensiones - Descripción de datos - WarBattle 4.8 Acciones sobre las habilidades militares En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto a las habilidades militares. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver habilidades militares del jugador Ver información sobre una habilidad militar Jugador Aumentar de nivel una habilidad militar Figura 3.3.61: Diagrama de casos de uso de acciones sobre las habilidades militares Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 147 Caso de uso 27: Ver habilidades militares del jugador El jugador elige la opción “Habilidad” del panel de opciones del margen superior del interfaz de juego. Figura 3.3.62: Interfaz del juego Opción habilidad: Figura 3.3.63: Opción habilidad 148 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona la opción ver habilidades militares. 2. El sistema realiza la lectura de las habilidades militares que posee el jugador. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 149 Caso de uso 28: Ver información sobre una habilidad militar Este caso de uso puede provenir de dos diferentes casos de uso, tanto del caso de uso 27 Ver habilidades militares como del caso de uso 15 Acceder a la academia militar. La diferencia que existirá entre uno y otro será el número de habilidades militares a mostrar y la opción de que puede aumentarse de nivel que estará bloqueada si proviene del caso de uso 25 Ver habilidades militares. En cualquier caso en ambas situaciones al pulsar sobre cualquier habilidad militar aparecerá la información relativa a ésta. En ambos casos también el formato del interfaz antes de seleccionar la habilidad militar de la que se quiere adquirir información será el siguiente: Figura 3.3.64: Vista común de la opción habilidades y academia militar 150 WarBattle Al pulsar sobre cualquier imagen de una habilidad militar estando en la academia militar se mostrará la siguiente información: Figura 3.3.65: Interfaz de la academia militar Al pulsar sobre cualquier imagen de una habilidad militar al seleccionar la opción habilidad se mostrará la siguiente información: Figura 3.3.66: Interfaz de las habilidades Como se puede observar, las diferencias entre un formato y otro residen, básicamente, en la incorporación de información sobre el coste de desarrollo y el proceso de aumento de éste. 151 152 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2a. El jugador ha tenido que elegir la opción habilidad. 2b. El jugador ha tenido que elegir la opción acceder a la academia militar. 3. El jugador tiene habilidades militares que mostrar. Escenario primario 1. El usuario pulsa sobre la imagen de un tipo de habilidad militar. 2. El sistema realiza la lectura de la habilidad militar seleccionada y prepara la vista con la información de ésta para devolverla al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 29: Aumentar de nivel una habilidad militar El jugador, una vez ha seleccionado una habilidad militar y viniendo del caso de uso 15 Acceder a la academia militar, elige la opción “Aumentar nivel” de la habilidad militar escogida. Figura 3.3.67: Información sobre una habilidad militar seleccionada Para aumentar de nivel la habilidad militar seleccionada debe estar habilitada la opción “Aumentar nivel” y pinchar sobre ella. Figura 3.3.68: Vista ampliada de la opción “Aumentar nivel” de una habilidad militar 153 154 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe haber elegido previamente la opción ver la academia militar. 3. El jugador debe haber elegido ver la información de una habilidad militar. 4. La opción de aumento de nivel debe estar habilitada. Escenario primario 1. El usuario elige la opción aumentar nivel. 2. El sistema realiza la lectura de la habilidad militar que se quiere aumentar de nivel y procede a realizar los cálculos y escrituras pertinentes sobre el proceso. Una vez realizados, prepara la vista de información general de la aldea y la devuelve al navegador del jugador. Extensiones - Descripción de datos - WarBattle 4.9 Acciones sobre el mapa En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto al tratamiento del mapa y del sistema de coordenadas. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver mapa Ver casilla Cambiar tierra Jugador Cambiar sector Cambiar coordenadas Figura 3.3.69: Diagrama de casos de uso de acciones sobre el mapa Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 155 Caso de uso 30: Ver mapa El jugador elige la opción “Mapa” del panel de opciones del margen superior del interfaz de juego. Figura 3.3.70: Interfaz del juego Opción mapa: Figura 3.3.71: Botón mapa 156 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario selecciona la opción ver mapa. 2. El sistema realiza la lectura del sector en el que está ubicada la aldea seleccionada del jugador que realiza la petición. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 157 Caso de uso 31: Ver casilla El jugador selecciona una casilla del mapa del tablero de la izquierda mientras está viendo algún sector específico del mapa. Figura 3.3.72: Interfaz del mapa Para ver información sobre la casilla el usuario tiene que pulsar sobre cualquiera de ellas para acceder a ella. Figura 3.3.73: Información de una casilla seleccionada 158 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe estar sobre la vista del mapa. Escenario primario 1. El usuario selecciona una casilla. 2. El sistema extrae la casilla escogida y realiza la lectura de la información contenida en ella. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 159 Caso de uso 32: Cambiar tierra El jugador selecciona cualquiera de las dos flechas del panel de tierra. El sistema en respuesta a esa petición debe ir a la siguiente tierra si se ha seleccionado la flecha de la derecha o a la anterior si se ha seleccionado la flecha de la izquierda. Figura 3.3.74: Interfaz del mapa Para cambiar de tierra hay que pulsar sobre cualquiera de las dos flechas que acompañan a los lados del cuadro de texto con el número de tierra actual. Figura 3.3.75: Botón de cambio de tierra 160 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe estar sobre la vista del mapa. Escenario primario 1. El usuario selecciona una de las dos direcciones de recorrido de las tierras (en sentido izquierdo o derecho). 2. El sistema extrae el sector actual y recoge la petición de recorrido. Una vez extraída la información realiza la lectura del sector que ha pedido el jugador. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 161 Caso de uso 33: Cambiar sector El jugador selecciona cualquiera de las dos flechas del panel de sector. El sistema en respuesta a esa petición debe ir al siguiente sector si se ha seleccionado la flecha de la derecha o al anterior si se ha seleccionado la flecha de la izquierda. Figura 3.3.76: Interfaz del mapa Para cambiar de sector hay que pulsar sobre cualquiera de las dos flechas que acompañan a los lados del cuadro de texto con el número de sector actual. Figura 3.3.77: Botón de cambio de sector 162 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe estar sobre la vista del mapa. Escenario primario 1. El usuario selecciona una de las dos direcciones de recorrido de los sectores (en sentido izquierdo o derecho). 2. El sistema extrae el sector actual y recoge la petición de recorrido. Una vez extraída la información realiza la lectura del sector que ha pedido el jugador. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 163 Caso de uso 34: Cambiar coordenadas El jugador accede a los cuadros de texto donde aparecen las coordenadas (tierra y región) y modifica los datos por los de las coordenadas a las que quiere acceder. El sistema los recoge y muestra la información del sector seleccionado. Figura 3.3.78: Interfaz del mapa Para cambiar de coordenadas se cambian los números de tierra y región y se pulsa el botón ver (también es válido utilizar la tecla Enter). Figura 3.3.79: Casillas de cambio de coordenadas 164 WarBattle Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2. El jugador debe estar sobre la vista del mapa. Escenario primario 1. El usuario modifica o no los valores de las casillas tierra y región y pulse Ver. 2. El sistema extrae las coordenadas de la tierra y el sector que ha introducido el jugador. Una vez extraída la información realiza la lectura del sector que ha pedido el jugador. A continuación prepara la vista y la devuelve al navegador del jugador. Extensiones - Descripción de datos - 165 4.10 Acciones sobre misiones En esta sección se realizará el estudio sobre las funciones que debe aportar el sistema respecto al tratamiento del mapa y del sistema de coordenadas. Las unidades de trabajo de este dominio se reflejan en el siguiente diagrama de casos de uso: Ver misiones activas Ver tiempo de duración de un viaje Jugador Crear misión Figura 3.3.80: Diagrama de casos de uso de acciones sobre las misiones Estos casos de uso ya se realizan sobre el interfaz del juego y el jugador debe haber sido validado y aceptado por el sistema. 166 WarBattle Caso de uso 35: Ver misiones activas El jugador elige sobre el panel de opciones de la parte superior la opción “Misiones”. Figura 3.3.81: Interfaz del juego Se genera la siguiente vista donde aparecen las misiones que tiene un usuario en el momento del envío del evento. Figura 3.3.82: Panel de información sobre las misiones 167 168 Actor primario Jugador Actores secundarios - Trigger - Precondiciones El jugador debe haber accedido al juego. Escenario primario 1. El usuario elige la opción misiones. 2. El sistema extrae misiones en curso del jugador que realiza la petición, prepara la vista y la envía al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 36: Ver tiempo de duración de un viaje El jugador desea conocer el tiempo de viaje de un conjunto de tropas desde la aldea en la que se encuentran hasta una casilla distinta. Para poder llevar a cabo esta unidad de trabajo, el jugador debe haber seleccionado la opción Tropas y elegido unas coordenadas distintas o desde el mapa al pulsar sobre cualquier casilla haber escogido alguna de las opciones de misiones disponibles. En ambos casos deberá seleccionar, además, al menos una unidad. Figura 3.3.83: Interfaz de las unidades disponibles para misiones Para calcular el tiempo el jugador debe seleccionar unas coordenadas y al menos una unidad. A continuación deberá pulsar sobre el botón calcular tiempo para obtener dicha información. Figura 3.3.84: Elementos participantes en el cálculo del tiempo de viaje 169 170 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2a. El jugador selecciona la opción Tropa. 2b. El jugador escogió una misión al pulsar sobre una casilla del mapa. 3. El jugador debe, al menos, seleccionar algún tipo de unidad y elegir unas coordenadas de destino. Escenario primario 1. El usuario elige la opción Calcular tiempo. 2. El sistema extrae las unidades elegidas, las coordenadas de destino y junto a las coordenadas de la aldea del jugador que se encuentra seleccionada y la bonificación de velocidad del jugador que realiza la petición, calcula el tiempo de viaje, prepara la vista y la envía al navegador. Extensiones - Descripción de datos - WarBattle Caso de uso 37: Crear misión El jugador desea crear una misión con un conjunto de tropas desde la aldea en la que se encuentran hasta una casilla distinta. Para poder llevar a cabo esta unidad de trabajo, el jugador debe haber seleccionado la opción Tropas y elegido unas coordenadas distintas o desde el mapa al pulsar sobre cualquier casilla haber escogido alguna de las opciones de misiones disponibles. En ambos casos deberá seleccionar, además, al menos una unidad. Figura 3.3.85: Interfaz de las unidades disponibles para misiones Para crear una misión el jugador debe seleccionar unas coordenadas y al menos una unidad. A continuación deberá pulsar sobre el botón aceptar empezar la misión deseada. Figura 3.3.86: Vista ampliada de la opción “Aceptar” misión 171 172 Actor primario Jugador Actores secundarios - Trigger - Precondiciones 1. El jugador debe haber accedido al juego. 2a. El jugador selecciona la opción Tropa. 2b. El jugador escogió una misión al pulsar sobre una casilla del mapa. 3. El jugador debe, al menos, seleccionar algún tipo de unidad y elegir unas coordenadas de destino. Escenario primario 1. El usuario elige la opción Aceptar. 2. El sistema extrae las unidades elegidas, las coordenadas de destino y junto a las coordenadas de la aldea del jugador que se encuentra seleccionada y la bonificación de velocidad del jugador que realiza la petición, da de alta la nueva misión. Acto seguido prepara la vista de información general de la aldea y la envía al navegador. Extensiones - Descripción de datos - WarBattle Problemas y errores 5. El análisis de requisitos ha sido un proceso largo y difícil. Han sido necesarias varias iteraciones hasta encontrar una solución estable y que reflejase correctamente todos los elementos del universo Warbattle. Las mayores dificultades se encontraron al comienzo del proceso de estudio. Las causas fueron diversas: Inexperiencia en análisis de sistemas software. Se realizaron múltiples pruebas de entrenamiento antes de empezar tan siquiera a realizar algún avance. Equivocación en el planteamiento. Durante los primeros meses se intentó exponer el estudio sin separarlo en grupos, es decir, todo el proceso se hacía sobre todo el sistema. Como se ha visto a lo largo del análisis de requisitos, esto era prácticamente una locura, pues el sistema tiene un volumen considerable para abordarlo de un golpe. Tamaño del entorno. Como se ha visto en el anterior epígrafe, el universo Warbattle tiene un tamaño considerable, lo que le aporta de forma innata una dificultad extra. Creación del entorno desde cero. Este estudio se realizó sin ninguna especificación del sistema ni documentos que especificasen algún requisito. Por ello, además del proceso habitual típico del análisis de requisitos en la ingeniería del software, fue necesario un proceso de creación de un universo con sus propias reglas. Dificultad de representación de varios conceptos. Como ya se vio en varios puntos del análisis, el entorno Warbattle posee elementos que implican una dificultad alta en su representación. Ejemplos claros de éstos son las restricciones entre elementos. Abstracción. Este proceso siempre implica dificultades, pues no es lo mismo realizar un estudio sobre algo ya creado que tener que imaginar muchísimos conceptos relacionados entre sí. Factor tiempo. Es un elemento crítico del sistema sobre el que se basa todo el funcionamiento del universo Warbattle. Crear sistemas críticos en el tiempo siempre es una tarea difícil para los analistas de sistemas. Debido a todas las causas vistas, el número de errores cometidos hasta alcanzar una solución estable fue bastante elevado. Quizás los más destacables fueron los siguientes: Al principio se tendía a particularizar en exceso. Posiblemente, el hecho de cambiar la estrategia al extremo contrario, el de intentar generalizar lo máximo posible hizo posible que, llegado a un punto, el análisis pudiera avanzar de forma más fluida. 173 Durante los primeros meses también se cayó en el error de no contar con ninguna herramienta con la que se pudiesen observar y encontrar los elementos que iban a constituir la estructura de Warbattle. Este suceso fue aliviado en cuanto se empezaron a utilizar borradores del interfaz de usuario desde el que poder ver qué elementos eran necesarios y cuáles no. 174 WarBattle Conclusiones 6. Una vez finalizado el análisis de requisitos se pueden extraer una serie de conclusiones de este importante proceso dentro de la ingeniería del software. Por un lado, se hace un balance muy positivo del trabajo realizado. El estudio que se ha llevado a cabo marcará de una forma más clara y estructurada las pautas a seguir en el siguiente paso: el diseño del sistema. Como siempre ocurre al cometer errores, lo importante de ellos es aprender y ganar en experiencia en ocasiones similares que se puedan presentar en el futuro. En mi caso, debo reconocer que a lo largo del proceso, debido a mi inexperiencia, he cometido muchísimos errores de todo tipo como hemos visto en el anterior punto. Gracias a ello, creo que, aunque aún me quede mucho trabajo por recorrer, este análisis, junto a lo aprendido durante mis cinco años de carrera, ha afianzado mis capacidades para el análisis de sistemas software. El siguiente paso en la construcción del juego será realizar el diseño del sistema. 175 176 WarBattle CAPÍTULO 4 Diseño 177 Introducción 1. En este tema se va a abordar el proceso de diseño del sistema incluido en el proceso de ingeniería del software. Antes de empezar conviene recordar en qué consiste este proceso. El diseño de un sistema realiza una descomposición y organización del mismo en elementos que puedan elaborarse por separado, aprovechando el principio fundamental de la informática “divide y vencerás”. Como resultado se consigue una estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Los pasos habituales en este proceso desde la aparición de la metodología UML 2.0 suelen ser: - Diseño de la arquitectura lógica. Diseño de la base de datos. Realización de diagramas de clases. Diseño funcional del sistema: o Diagramas de secuencia. o Diagramas de actividad. o Diagramas de flujo de trabajo. Debido al tamaño del sistema y que esta documentación tiene un carácter académico, se realizará sólo la documentación de parte de estos procesos, ya que de realizarla sobre todos ellos, el documento alcanzaría un número de páginas muy superior a lo recomendable. Los procesos que se van a documentar y que, por tanto, van a suponer el caso de estudio en este tema son los siguientes: Diseño de la arquitectura lógica. Se definirá la estructura del sistema a un nivel alto. Diseño de la base de datos. Se explicará el modelo seguido para construir la base de datos del sistema. Diagramas de clase. Sólo de aquellas clases cuyo contenido no sea obvio y que tengan una importancia fundamental en el sistema. Explicación de los algoritmos más importantes. Sustituirá en parte al proceso de diseño funcional del sistema, simplificándolo bastante y limitándose a realizar unas definiciones y descripciones breves del funcionamiento de éstos. Exposición de los problemas encontrados y los errores cometidos. 178 WarBattle - Conclusiones técnicas y personales del proceso de diseño. Los diagramas de secuencia no se realizarán por su elevado volumen. De todas maneras, una vez realizado el diseño de la arquitectura y de las clases y módulos del sistema se podrán intuir éstos de los diagramas de caso de uso que se realizaron en el análisis de requisitos. 179 Arquitectura lógica 2. Este capítulo recoge el proceso de diseño de la estructura global del sistema. Este proceso es fundamental en el diseño, pues, debido al tamaño del sistema, es necesario utilizar una estrategia de división del problema en subproblemas para facilitar el trabajo. Otro de los motivos e igual de importante es la idea de especialización de módulos. Para que el sistema sea modulable es necesario definir una serie de funciones de alto nivel de las que deberá componerse el sistema. Para ello, la arquitectura del sistema se basará en el patrón MVC (modelo-vistacontrolador). Este patrón es un estándar en las arquitecturas web debido a sus características. Divide el sistema en tres grandes módulos, cada uno encargado de una tarea específica. Las funciones de las que se encargan cada uno son: Modelo: define los elementos a los que el usuario tendrá acceso. Controlador: gestiona las peticiones del usuario, realiza los cálculos deseados y prepara los datos de respuesta. Vista: recibe los datos de respuesta y prepara la salida que espera el usuario a su petición. Las relaciones entre estos módulos son: Figura 4.1.1: Arquitectura MVC 180 WarBattle En base a este patrón de arquitectura, se ha elaborado una solución parecida para abordar el diseño del sistema. La arquitectura lógica estará compuesta por cinco grandes módulos, que son: - Dominio. Controlador. Vista. Motor. DAO. La relación entre ellos se puede apreciar en el siguiente diagrama: Figura 4.1.2: Arquitectura del sistema Warbattle A continuación se explicará en profundidad cada uno de los módulos del sistema. 181 2.1 Dominio Este módulo se encarga de la representación lógica de todos los elementos que conforman el universo “físico” de Warbattle. En él se recogerán tanto las clases que recogen la información de las tablas de la base de datos, como aquéllas cuyo contenido no se refleje de manera estable en el sistema pero que representa conceptos del universo Warbattle. Este módulo estará compuesto por dos grandes paquetes de información y trabajo en función del contenido que representan. El contenido de los elementos puede ser estático o dinámico. Por tanto, los dos paquetes que conformarán este módulo son: Grupo estático: contendrá la representación de los contenidos de carácter estático del sistema. Esos contenidos son los que guardan información sobre las características de los elementos del juego, tales como información sobre tipos de edificios, de unidades militares, etc. Grupo dinámico: sus contenidos corresponderán con información del jugador y de los elementos que posee. La información en este paquete estará continuamente sujeta a cambios y modificaciones. La siguiente figura representa la estructura del módulo Dominio. Figura 4.1.3: Estructura del módulo dominio 182 WarBattle 2.2 Controlador Este módulo es el encargado de realizar el control del sistema en función de las peticiones de los jugadores. Las clases de este módulo tienen la función de recibir las peticiones de los jugadores. Una vez recibidas deben escoger quién será el encargado de realizar los cálculos que requieran la operación pedida y extraer la información necesaria. Una vez recibida la respuesta del encargado de los cálculos debe ser capaz de escoger cual será el paquete que prepare la salida como respuesta a la petición del jugador. Debido a la naturaleza del módulo, en él se encontrarán los Servlets del sistema, que tienen precisamente las características necesarias para realizar este tipo de labor. A su vez, este módulo estará compuesto por dos paquetes de trabajo, cada uno con una función similar pero diferente al mismo tiempo. Esta división se realiza debido a que el juego puede manejar dos tipos de peticiones, síncronas y asíncronas. Así pues, los paquetes de trabajo en que está dividido el módulo Controlador son: Control síncrono: contendrá los Servlets encargados de las peticiones síncronas de los jugadores. Este paquete una vez realizados los cálculos necesarios para generar la vista cederá el control al módulo Vista que es el contiene los conocimientos necesarios para generar contenido HTML síncrono. Control asíncrono: contendrá por su parte los Servlets encargados de las peticiones asíncronas de los jugadores. Para ello, el sistema utilizará la tecnología AJAX, por lo que además de las funciones descritas para el módulo al completo, también se encargará de generar el contenido HTML de respuesta. El contenido del módulo Controlador junto a las relaciones con el módulo Vista son las siguientes: 183 Figura 4.1.4: Estructura del módulo controlador 184 WarBattle 2.3 Vista Este módulo se encarga de realizar el interfaz de juego con el que se encontrará el jugador en respuesta a su petición. En él estarán todas las clases relacionadas con la preparación de las diferentes páginas Web que forman todo el interfaz de jugabilidad. Debido a la comodidad y escalabilidad que proporciona la división en paquetes de trabajo específicos, este módulo estará formado por diversos paquetes de trabajo, cada uno de ellos encargado de una tecnología Web diferente, tal y como recomiendan los estándares. Los paquetes de trabajo son: Javascript: incluye los ficheros con las funciones javascript usadas en el interfaz de usuario. CSS: incluye los documentos CSS 2.1 con la información sobre el aspecto del interfaz de usuario. Image: alberga las imágenes que serán mostradas en el interfaz de usuario. Web: formado por los documentos .jsp y .html que incluirán la estructura y la información del interfaz de usuario. La siguiente figura refleja los contenidos expuestos en esta sección: Figura 4.1.5: Estructura del módulo vista 185 2.4 Motor Este módulo es el encargado de realizar que las reglas del universo Warbattle funcionen. Como su propio nombre indica, su contenido forma el motor del juego. Entre sus funciones se pueden destacar las siguientes: Proporciona un interfaz de funciones que serán usadas por el módulo controlador para generar las respuestas sobre las peticiones de los jugadores. Realiza el control sobre todos los elementos críticos del sistema, así como de la gestión de la concurrencia, de la gestión del tiempo, etc. Define una serie de herramientas de uso global. Así pues, entre otros elementos, este módulo contendrá los Beans de sesión, tal y como define la tecnología JEE 5 utilizada en el servidor de aplicaciones. El módulo Motor está compuesto por cuatro paquetes de trabajo, cada uno con una misión específica y completamente diferente al resto. Estos paquetes de trabajo son: Fachada: este paquete reúne los Session Beans del servidor de aplicaciones. Aporta una serie de clases que proporcionan un conjunto de funciones de acceso al sistema desde el módulo Controlador. Este paquete de trabajo, además, actúa de intermediario entre los módulos Controlador y DAO (en la siguiente sección se explicará el contenido de este módulo). Actualizador: se encarga de la correcta gestión de la concurrencia de eventos y del tiempo. Realiza las funciones de actualización necesarias por la llegada de eventos externos al sistema. De esta forma no se producirán problemas de incoherencia en los datos. Herramientas: este paquete aporta un interfaz de funciones que aportan herramientas de trabajo utilizadas por todos los módulos a excepción del módulo Vista. Algunas de las funciones que aporta este interfaz son: Parser y formateo de cadenas de caracteres. Tratamiento de fechas. Manejo de ficheros y contenidos XML. Misiones: su función es realizar los cálculos necesarios para que los jugadores puedan llevar a cabo este tipo de funciones. 186 WarBattle La estructura del módulo Motor se resume en la siguiente imagen: Figura 4.1.6: Estructura del módulo motor 187 2.5 DAO Este módulo reúne las clases encargadas de los accesos, tanto de lectura como de escritura, sobre la base de datos. Si hablásemos de una arquitectura distribuida, este módulo correspondería con las funciones alojadas en el servidor de base de datos. Como se ha visto anteriormente al definir el módulo Dominio, existen dos tipos de contenidos estables, de carácter estático y de carácter dinámico. Debido a ello, este módulo se ha decidido dividir en dos grandes paquetes de trabajo encargados cada uno de gestionar cada tipo de información. Así pues, los paquetes de trabajo que forman este módulo son: Gestor estático: se encarga de los accesos a la base de datos de la información de carácter estático, tales como las características de los tipos de edificios, unidades, etc. Gestor dinámico: este paquete de trabajo se encarga de la consistencia de los datos relacionados con la información de carácter dinámico de los jugadores, cuyo contenido cambia constantemente y difiere de unos jugadores a otros. La estructura de este módulo se resume en el siguiente diagrama: Figura 4.1.7: Estructura del módulo DAO 188 WarBattle Diseño de la base de datos 3. En este capítulo se va a realizar el estudio y diseño de la base de datos que compondrá el sistema Warbattle. Este proceso consistirá en la definición, creación y diseño de las tablas de la base de datos, así como de las relaciones entre ellas. En los posteriores diagramas de la base de datos se dibujarán rectas de unión entre tablas que expresarán la relación entre ellas de multiplicidad. Por otro lado, en cada tabla se incluirá la siguiente información: - Clave primaria. Atributos en caso de que los tenga. Claves foráneas en caso de que existan. Una vez visto el formato interno de las tablas que serán definidas a lo largo del capítulo, es necesario indicar los tipos de tablas que se encontrarán. Para clasificar los tipos de tablas del sistema Warbattle es necesario realizar dos métodos diferentes. El primero clasifica las tablas en función del trabajo que desempeñan en la base de datos. El segundo lo hace en relación a su contenido respecto al juego en sí. La primera clasificación genera dos tipos de tablas, que son: Tablas de información del juego: estas tablas contienen información sobre el juego, con datos relativos a los jugadores y sus elementos o a la información sobre las reglas y características de éste. Son tablas con una serie de atributos que definen las características del elemento representado por la tabla. Por lo general, al realizar el diseño se pondrá un cuidado especial en utilizar nombres significativos y representativos con los conceptos del juego que almacenan. Tablas de relación entre tablas: estas tablas sirven para relacionar tablas entre sí. El motivo de la existencia de este tipo de tablas es la facilitación de acceso a datos entre tablas difícilmente relacionadas entre ellas. La segunda clasificación genera también dos tipos de tabla, a saber: Tablas de información estática: este tipo de tabla contiene la información sobre las reglas y características del juego Warbattle. 189 El contenido de estas tablas será de carácter estático y de lectura, es decir, la información que contiene no se verá alterada en ningún momento y será consultada por el sistema para hacer que el juego funcione. Por otro lado, estas tablas estarán relacionadas con las de contenido dinámico. Tablas de información dinámica: estas tablas contendrán la información sobre los jugadores y los elementos que poseen. Su contenido estará constantemente en transformación, por lo que su contenido será de carácter dinámico y de lectura y escritura. Este tipo de tablas estarán también relacionadas con las de contenido estático. Desde el punto de vista de los tipos de datos de las tablas, todas ellas utilizarán como clave primaria el tipo ‘Bigint(20)’, que será transformada a Long en Java. Por último, antes de comenzar el diseño de las tablas, debido al tamaño de la base de datos Warbattle, se dividirán en grupos de contenido relacionado entre sí. Los grupos de diseño serán: - - 190 Estáticos: o Tipos de elementos. o Costes y producción. Dinámicos: o Elementos de los usuarios. o Elementos de las aldeas. o Elementos de los productores. o Elementos de los edificios. o Elementos de las ciencias. o Elementos de las habilidades militares. o Elementos de las unidades militares. o Elementos de las unidades defensivas. o Elementos de las misiones. o Elementos del mapa. WarBattle 3.1 Tipos de elementos 3.2 Costes y producción 191 192 3.3 Elementos de los usuarios 3.4 Elementos de las aldeas WarBattle 3.5 Elementos de los productores y edificios Elementos de las ciencias y habilidades militares 3.6 193 194 3.7 Elementos de las unidades militares 3.8 Elementos de las unidades defensivas WarBattle 3.9 Elementos de las misiones 3.10 Elementos del mapa 195 Algoritmos significativos 4. Este capítulo recoge la descripción de aquellos algoritmos que se han considerado de mayor importancia y dificultad. Su contenido tiene una complejidad mayor que el resto y no son tan obvios. Para describirlos se usará la siguiente metodología: Descripción breve del algoritmo con lenguaje natural. Se explicará en qué consiste y en qué contexto se utiliza. Uso de diagramas de flujo para representar el funcionamiento interno de los algoritmos. Uso de diagramas de secuencia que reflejen la relación entre clases participantes en el algoritmo. Los algoritmos que van a ser descritos en este capítulo son: 1. Alta usuarios. 2. Actualizar. 3. Construcción de unidades militares. 4. Alta misiones. 196 WarBattle 4.1 Alta usuario Esta función realiza el ingreso de un nuevo jugador en el sistema. Para que se lleve a cabo esta misión, los datos introducidos durante el registro deben ser válidos. Una vez aceptados los datos de entrada, se procede a la ejecución del algoritmo de alta de usuarios, objeto de estudio en esta sección. Al finalizar el proceso, se dará acceso al jugador al sistema. El diagrama de flujo que representa las funciones de las que se compone el algoritmo es: INICIO TRANSACCION ALTA USUARIO ALTA CIENCIAS BLOQUEADAS ALTA HABILIDADES BLOQUEADAS ALTA ALDEA FIN TRANSACCION 197 A su vez, el proceso Alta aldea está compuesto de las siguientes funciones: ALTA RECURSOS ALTA EDIFICIOS ALTA EDIFICIOS BLOQUEADOS ALTA PRODUCTORES ALTA UNIDADES BLOQUEADAS ALTA DEFENSAS BLOQUEADAS 198 WarBattle El diagrama de secuencia que se muestra a continuación indica las relaciones existentes entre las clases participantes: ServicioUsuario GestorTransacción iniciaTransaccion() conexion GestorUsuario altaUsuario(datosUsuario) usuario GestorCiencias altaCienciasBloqueadas(usuario) GestorHabilidades altaHabilidadesBloqueadas(usuario) GestorAldeas altaAldea(usuario) aldea GestorRecursos altaRecursos(aldea) GestorEdificios altaEdificios(aldea) GestorProductores altaProductores(aldea) GestorUnidades altaUnidadesBloqueadas(aldea) GestorDefensas altaDefensasBloqueadas(aldea) FinTransaccion(conexion) 199 4.2 Actualizar Este proceso es el más complejo y, seguramente, importante de todos los que componen el sistema. Realiza todos los cálculos sobre los sucesos ocurridos desde el último evento que hizo participar a una aldea (externo o del propio jugador) hasta el último, motivo por el que se activa el proceso. Puesto que todos los elementos del jugador pueden estar sujetos a cambios es necesario realizar un barrido acerca de lo sucedido entre los dos eventos en todos ellos. El algoritmo de actualización se puede representar por el diagrama de flujo de la siguiente página: 200 WarBattle INICIO TRANSICION ACTUALIZACION EXTERNA ACTUALIZACION MISIONES IDA ACTUALIZACION MISIONES VUELTA ACTUALIZACION EDIFICIOS ACTUALIZACION CIENCIAS ACTUALIZACION HABILIDADES ACTUALIZACION UNIDADES ACTUALIZACION DEFENSAS ACTUALIZACION RECURSOS FIN TRANSACCION 201 A continuación se realizarán los diagramas de flujo que explican el funcionamiento de cada proceso hijo: Actualización externa COMPROBACION MISIONES ENTRANTES si ¿Hay misiones? no ¿Hora actual < hora destino? si no ACTUALIZACION HASTA HORA DESTINO EJECUTAR MISION ENTRANTE no 202 ¿Más misiones? si WarBattle Actualización misiones ida COMPROBAR MISIONES PENDIENTES si no ¿Había? COMPROBAR FINALIZACION no si ¿Finalizada? COMPROBAR TIPO DE MISION COMPROBAR POSICION DESTINO colonizar Tipo otro si no ¿Libre? ACTUALIZAR DESTINO ALTA ALDEA REALIZAR MISION BAJA MISION PREPARAR VUELTA si ¿Más misiones? no 203 Actualización misiones vuelta COMPROBAR HORA VUELTA no si ¿Ha vuelto? ACTUALIZAR RECURSOS ACTUALIZAR TROPAS BORRAR MISION 204 WarBattle Actualización edificios COMPROBACION EDIFICIOS PENDIENTES si no ¿Hay? COMPROBACION FINALIZACION si no ¿Finalizado? ACTUALIZA EDIFICIO COMPROBACION DE DESBLOQUEOS no si ¿Desbloquea? ELIMINA BLOQUEO no ¿Elemento desbloqueado? si ALTA ELEMENTO BLOQUEADO 205 Actualización ciencias COMPROBAR BIBLIOTECAS PENDIENTES no COMPROBACION CIENCIA PENDIENTE ¿Hay? si si COMPROBAR FINALIZACION COMPROBAR FINALIZACION ¿Hay? no si AUMENTAR NIVEL ¿Finalizado? no ¿Finalizado? si no COMPROBACION DESBLOQUEOS AUMENTAR NIVEL ¿Desbloquea? COMPROBACION DESBLOQUEOS no si no ALTA CIENCIA ¿Desbloquea? si BAJA BLOQUEO CIENCIA ALTA ELEMENTO BLOQUEADO BAJA BLOQUEO Actualización habilidades 206 WarBattle COMPROBAR ACADEMIAS PENDIENTES no COMPROBACION HABILIDAD PENDIENTE ¿Hay? si si COMPROBAR FINALIZACION COMPROBAR FINALIZACION ¿Hay? no si AUMENTAR NIVEL ¿Finalizado? no ¿Finalizado? si no COMPROBACION DESBLOQUEOS AUMENTAR NIVEL ¿Desbloquea? COMPROBACION DESBLOQUEOS no si no ALTA HABILIDAD ¿Desbloquea? si BAJA BLOQUEO HABILIDAD ALTA ELEMENTO BLOQUEADO BAJA BLOQUEO 207 Actualización unidades COMPROBACION UNIDADES PENDIENTES no si ¿Pendientes? COMPROBACION FINALIZACION ALTA UNIDADES ASIGNACION EJERCITO Actualización defensas COMPROBACION DEFENSAS PENDIENTES no si ¿Pendientes? COMPROBACION FINALIZACION ALTA DEFENSAS ASIGNACION ALDEA 208 WarBattle Actualización recursos COMPROBACION PRODUCTOR PENDIENTE si ¿Hay? no COMPROBACION FINALIZACION no si ¿Finalizado? EXTRACCION DATOS ANTERIORES CALCULO UNIDADES PRODUCIDAS CALCULO PRODUCCION HASTA CONSTRUCCION CALCULO PRODUCCION NUEVA ACTUALIZACION UNIDADES 209 El diagrama de secuencia que se muestra a continuación indica las relaciones existentes entre las clases participantes ServicioActualizacion GestorTransaccion iniciaTransaccion() conexion ActualizadorMisiones actualizaMisionesIda(aldea) ActualizadorMisiones actualizaMisionesIda(aldea) actualizaMisionesVuelta(aldea) ActualizadorEdificios actualizaEdificios(aldea) ActualizadorCiencias actualizaCiencias(usuario) ActualizadorHabilidades actualizaHabilidades(usuario) ActualizadorUnidades actualizaUnidades(aldea) ActualizadorDefensas actualizaDefensas(aldea) ActualizadorRecursos actualizaRecursos(aldea) finTransaccion(conexion) 210 WarBattle 4.3 Construcción de unidades militares Este proceso se encarga de dar de alta la construcción de las unidades militares que el jugador solicita. El siguiente diagrama muestra el funcionamiento: LECTURA RECURSOS LECTURA COSTE UNIDAD CALCULAR COSTE UNIDADES IGUALES ESCRITURA UNIDADES PENDIENTES ¿Más unidades? si no ACTUALIZAR RECURSOS Este algoritmo se lleva a cabo en la clase GestorUnidades del módulo DAO, por eso no se mostrará el diagrama de secuencia pertinente. 211 4.4 Alta misiones Este proceso lleva a cabo, como su nombre indica, el alta de una nueva misión como respuesta a la solicitud del jugador. El siguiente diagrama muestra el funcionamiento de éste: COMPROBACION UNIDADES DISPONIBLES ¿Menos disponibles que solicitadas? si no AJUSTE UNIDADES si COMPROBACION RECURSOS DISPONIBLES ¿Menos disponibles que solicitadas? no ¿Mision == colonizar || espionaje? AJUSTE RECURSOS COMPROBACION CONVOY O ESPIA EN UNIDADES si no no ¿Está? si ACTUALIZAR UNIDADES Y RECURSOS EN ALDEA ¿Puede? si COMPROBAR OTRAS POSIBLES RESTRICCIONES no ALTA MISION Este algoritmo lo realiza al completo la clase GestorMisiones del módulo DAO, por lo que no es necesario mostrar el diagrama de secuencia pertinente. 212 WarBattle Problemas y errores 5. En este capítulo se van a describir los problemas que surgieron durante la fase de diseño, así como los errores cometidos con el fin de que queden documentados para evitarlos en posteriores trabajos. Los problemas más importantes y significativos que se encontraron en esta fase del proyecto fueron: Inexperiencia en diseño de sistemas de gran volumen. Debido a ello, fueron múltiples las iteraciones realizadas hasta alcanzar un modelo estable. Módulos críticos. El hecho de que el sistema albergue gran cantidad de procesos que accedan a recursos compartidos por un número tan elevado de usuarios provocó que durante la etapa de diseño se obviarán determinadas relaciones que más tarde se dio buena cuenta de que eran imprescindibles. Necesidad de realizar un sistema fácilmente escalable. Debido a que a mitad del análisis de requisitos se comenzaron esta tarea y la de programación en paralelo para ir realizando pruebas, era indispensable que durante el diseño se tuviese en cuenta esta necesidad, ya que a medida que del análisis surgían elementos debían poderse acoplar fácilmente al sistema diseñado hasta ese momento. Problemas con el interfaz de acceso a datos en la programación. Este fue, quizás, el mayor problema que apareció durante la fase de diseño. En un primer momento se planteó para realizar los accesos a la base de datos la tecnología de reciente aparición JPA de Java. Esta tecnología aportaba al programador y al diseñador la comodidad de no tener que encargarse de ninguna clase de acceso a datos específica, pues en gran medida esta tecnología encapsula el proceso. Lo que en principio pareció una facilidad enorme al avanzar en la fase de programación llegó un momento en el que la tecnología aportaba más problemas que soluciones. El principal fue que el control sobre las escrituras sobre la base de datos recaía completamente sobre la tecnología, eligiendo su propio gestor los instantes en que debían hacerse las actualizaciones. Como consecuencia de ello, los datos acostumbraban a quedar en estados incoherentes e inestables, con los consecuentes problemas que este suceso generaba. Como solución se optó por utilizar una tecnología que implicaba más trabajo a la programación pero que aportaba control absoluto sobre las actualizaciones de la base de datos. Esta tecnología fue el api de la JDK 1.6 JDBC para acceso a base de datos. 213 Por tanto, a la arquitectura le faltaba un módulo que se encargase de la base de datos. El módulo que se eligió fue, como se ha descrito anteriormente, el módulo DAO. Por último, no sólo fue necesario añadir un nuevo módulo, sino que el diseño anterior quedó en gran parte obsoleto. Fue necesario un proceso de re-análisis hasta alcanzar la solución que ha sido objeto de estudio a lo largo de este capítulo. 214 WarBattle Conclusiones 6. Al término de la fase de diseño del sistema Warbattle se pueden extraer las siguientes conclusiones: Necesidad de realización de un buen diseño como parte fundamental en el desarrollo de software de grandes sistemas. El motivo es la limpieza y facilidad con que el trabajo en la siguiente fase, la de programación, se va a llevar a cabo. Alto grado de aprendizaje y experiencia. Durante esta fase he tenido que enfrentarme a diversos retos completamente nuevos para mí que me han aportado una fluida habilidad para percibir con mayor facilidad conceptos fundamentales a la hora de diseñar y de poder plasmarlos en los diagramas que mejor representen cada caso. Satisfacción personal por haber superado las dificultades encontradas y, como mencioné en el anterior epígrafe, por haber aprendido mucho del proceso de ingeniería del software. A continuación deberían aparecer la documentación relativa al proceso de programación y, más adelante, al de pruebas e implantación. Debido al tamaño que supondría el documento total, no se describirán estos procesos. 215 216 WarBattle CAPÍTULO 5 Trabajo futuro 217 En este capítulo se tratará los trabajos futuros que se realizarán sobre el sistema una vez montado. Una vez creado el producto, el siguiente paso será su comercialización. Puesto que Warbattle es un juego destinado a Internet su fuente de ingresos será básicamente dos: Cesión de espacio en la página para alojar banners de publicidad de otras empresas. Oferta de ventajas o comodidades en el juego que el jugador paga por ellas por un determinado tiempo. A la fecha de terminación del proyecto no se han considerado ninguna de las dos posibilidades, por lo que en ambos casos requeriría incluir funcionalidades nuevas al sistema. Como ya se insistió en la fase de diseño, un requisito fundamental era conseguir que el sistema fuese escalable, entre otras cosas porque ya entonces se previó que en un futuro se pudiese comercializar, lo que implicaría añadir nuevos módulos. Por otro lado, para comercializar el producto son necesarios otros requisitos. Estos son: Contratación de un dominio: para que el acceso sea público el juego debe tener su propio dominio, lo que implica el alquiler o compra de una dirección IP y del nombre que se le va a asignar a la página. - Alquiler o compra de servidores donde alojar el sistema. - Implantación de medidas de seguridad. - Realización de un plan de mantenimiento y de backup en caso de fallo. Todos estos puntos serán estudiados en un trabajo futuro realizando un plan de viabilidad en el que se estimarán los ingresos que pueda producir el juego, así como los gastos derivados de él. En este plan se trazarán dos rutas alternativas que consistirá cada una en lo siguiente: 1º Se estimarán los gastos derivados de la contratación del hosting que aloje el juego delegando en un tercero el mantenimiento del sistema. 218 WarBattle 2º En la otra opción se contemplará la adquisición de los equipos, así como la contratación de líneas telefónicas y la creación de una empresa. Por último, para que el juego sea comercial, será necesario utilizar imágenes propias, ya que hasta el momento se han utilizado dos tipos de imágenes, unas con copyright ya que han sido extraídas de videojuegos actuales y otras que pertenecen a juegos del género abandonware, esto es, juegos que hace más de 10 años que no se comercializan y que han perdido los derechos de explotación, normalmente porque las empresas que los crearon han desaparecido. 219 220 WarBattle CAPÍTULO 6 Evaluación económica 221 En este capítulo se realizará una estimación económica del coste en el que se hubiese incurrido en la realización del proyecto en caso de que hubiese sido contratado por una empresa externa. En estos cálculos no se hará referencia alguna a los derivados de su posterior explotación, tales como hosting, compra de servidores, mantenimiento, etc. Es decir, en este capítulo sólo se estimarán los costes procedentes de las horas hombres empleadas. La siguiente tabla muestra los participantes en el desarrollo del juego, así como el número de cada uno de ellos, las horas empleadas, el coste por hora por rol y el coste total del mismo. ROL Nº Personas Horas Coste hora/hombre Coste total Coordinador 1 40 100 4.000 Director 1 80 80 6.400 Jefe de proyecto 1 80 60 4.800 Analista 1 100 50 5.000 Diseñador 1 150 40 6.000 Programador 2 100 30 6.000 Diseñador gráfico 1 50 15 750 222 HORAS TOTALES 700 horas PRESUPUESTO TOTAL 32.950 € WarBattle CAPÍTULO 7 Bibliografía 223 BIBLIOGRAFIA DE CONSULTA [JBA01] Jesús Barranco de Areba: “Metodología del análisis estructurado de sistemas”. ISBN: 84-8468-043-6. [EG02] Erich Gamma: “Patrones de diseño”. ISBN: 84-7829-059-1. [CHCG03] Cay S. Horstmann, Gary Cornell: “Core Java 2: Volumen 1 Fundamentos”. [CHCG04] Cay S. Horstmann, Gary Cornell: “Core Java 2: Volumen 2 Características Avanzadas”. [JLJLE05] Juan Benavides Abajo, Luis Martínez Fuentes, Juan María Olaizola Bartolomé, Luis Reina Juliá, Enrique Riverio Cornelio: “Introducción al SQL para usuarios y programadores”. [JCE06] Juan Carlos Esquivel Díaz: “Apuntes de la asignatura de Ingeniería del Software II”. 224 WarBattle ANEXO A Manual de usuario 225 Este anexo se ha elaborado para explicar las opciones que el interfaz del juego proporciona. Figura A.1: Interfaz del videojuego La figura A.1 muestra el interfaz del videojuego en el que se pueden apreciar dos grupos de opciones: uno en el lado izquierdo sobre un recuadro azul y el otro en la parte superior. Por otro lado, debajo de las opciones superiores se encuentran los recursos disponibles en la aldea, en el siguiente orden de aparición de izquierda a derecha: soldados, trigo, madera, piedra, hierro y especia. A su izquierda está la hora del sistema. En la esquina superior izquierda está el panel de castillos, donde se puede elegir cambiar la vista otro castillo del jugador. Por último, en el centro de la pantalla se muestra el tablero de juego. A continuación se explicarán cada una de las opciones integradas. 226 WarBattle Inicio Esta opción muestra la información general del castillo en el que el jugador esté realizando sus operaciones. Figura A.2: Vista general de un castillo Como se puede observar en la figura A.2 el tablero está dividido en dos partes: - A la izquierda se muestra la imagen del castillo seleccionado. - A la derecha hay un recuadro que representa los tiempos de construcción restantes en el castillo dividido en cuatro partes: o Productor en construcción. o Edificio en construcción. o Ciencia en investigación. o Habilidad en investigación. 227 Edificios Esta opción muestra los edificios que tenga construidos el jugador en el castillo seleccionado. Figura A.3: Vista de edificios de un castillo En la parte izquierda del tablero aparecen los edificios construidos en el castillo, mientras que en la parte izquierda hay un panel que mostrará la información del edificio pulsado, así como los accesos al mismo. 228 WarBattle Tropas Esta opción muestra las unidades disponibles en el castillo que pueden ser utilizadas para llevar a cabo misiones. Figura A.4: Vista de las tropas disponibles en un castillo En la parte izquierda del tablero aparecen las unidades militares disponibles en el castillo. Por otro lado, en la parte derecha se muestra un formulario con las opciones disponibles para llevar a cabo una misión. 229 Defensa Esta opción muestra las unidades defensivas del castillo seleccionado. Figura A.5: Defensas de un castillo Como se puede observar en la figura A.5 en la parte izquierda del tablero se encuentran las unidades defensivas que tiene el castillo y en la derecha se muestra un panel que, al pulsar sobre cualquier tipo de unidad, recoge la información de ella. 230 WarBattle Producción Esta opción muestra los productores que tiene un castillo, así como el nivel al que se encuentra y todas las opciones derivadas de ella. Figura A.6: Producción de un castillo En el panel de la izquierda se muestran las casillas con los productores del castillo y en el de la derecha la información relativa a cada uno de ellos que aparecerá al pulsar sobre cualquier productor. 231 Ciencia Esta opción muestra las ciencias que tiene un jugador así como el nivel al que está cada una de ellas. Figura A.7: Ciencias de un jugador En la parte izquierda aparecen las ciencias ya investigadas y a la derecha, al pulsar sobre cualquiera de ellas, la información de éstas. 232 WarBattle Habilidad Esta opción muestra las habilidades militares que tiene un jugador así como el nivel al que está cada una de ellas. Figura A.8: Habilidades militares de un jugador En la parte izquierda aparecen las habilidades ya investigadas y a la derecha, al pulsar sobre cualquiera de ellas, la información de éstas. 233 Misiones Esta opción muestra las misiones que el jugador tiene activas en el momento, así como la información de ellas. Figura A.9: Misiones de un jugador En la parte izquierda aparecen las misiones en curso y a la derecha, al pulsar sobre el icono “+” de cualquiera de ellas, la información de éstas. 234 WarBattle Mapa Esta opción muestra el mapa y permite ver diferentes regiones del mismo. Figura A.10: Mapa En la parte izquierda aparece el sector seleccionado (el del castillo por defecto) y a la derecha la información de la casilla seleccionada. 235 Mensajes Esta opción muestra los mensajes que tiene un jugador. Figura A.11: Mensajes de un jugador En la parte izquierda aparecen los mensajes del jugador y a la derecha, si procede, la información ampliada de los mismos. 236
