universidad pontificia comillas escuela tÉcnica … · 2009-09-15 · ingeniero en informÁtica...
TRANSCRIPT
PROYECTO FIN DE CARRERA
VIDEOJUEGO DE ESTRATEGIA PARA
NAVEGADORES WEB EN TIEMPO REAL:
WARBATTLE
AUTOR: HECTOR LOPEZ POMBO
MADRID, SEPTIEMBRE 2009
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
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: / /
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
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
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 medieval-fantá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
1
CAPÍTULO 1
Introducción
2
1.Introducción
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
WarBattle
3
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
4
2.Objetivos
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:
- 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
5
CAPÍTULO 2
Estado del arte
6
1.Historia de los videojuegos
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.
WarBattle
7
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.
8
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
WarBattle
9
2.Los Browser Games
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.
10
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
WarBattle
11
3.Metodología
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.
12
WarBattle
13
CAPÍTULO 3
Análisis de requisitos
14
1.Introducción
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.
WarBattle
15
2.Estudio de la ambientación
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.
16
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 * .
WarBattle
17
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.
18
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.
WarBattle
19
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.
20
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
WarBattle
21
- 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 * .
22
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:
- 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
23
- 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):
24
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
WarBattle
25
- 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
26
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.
WarBattle
27
- 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).
28
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
WarBattle
29
- 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
30
- 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.
WarBattle
31
- 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:
32
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).
WarBattle
33
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.
34
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
WarBattle
35
- 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
36
- 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
WarBattle
37
- 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
38
- 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
WarBattle
39
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.
40
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:
WarBattle
41
- 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
42
- 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
WarBattle
43
- 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.
44
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
WarBattle
45
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.
46
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.
WarBattle
47
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.
48
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.
WarBattle
49
2. Restricciones
En esta sección se analizarán las restricciones que van ligadas a la
naturaleza del universo Warbattle.
Elemento bloqueado Elemento que desbloquea
CIENCIAS
Mando Biblioteca nivel 2
Herramientas Biblioteca nivel 1
Forja del hierro Biblioteca nivel 2 Herramientas nivel 3
Imperio Biblioteca nivel 8 Mando nivel 7
Espionaje Biblioteca nivel 5 Mando nivel 5
Ocultar bienes Biblioteca nivel 10 Imperio nivel 4
Comercio Biblioteca nivel 8
HABILIDADES MILITARES
Ataque Academia militar nivel 2
Defensa Academia militar nivel 3
Vitalidad Academia militar nivel 5 Ataque nivel 2
Velocidad Academia militar nivel 4
Formación Academia militar nivel 8
Carga Academia militar nivel 4 Ataque nivel 6
Alcance Academia militar nivel 4 Velocidad nivel 2
Asalto Academia militar nivel 10 Ataque nivel 10
EDIFICIOS
Almacén subterráneo Ocultar bienes nivel 8
Fragua Forja del hierro nivel 4
Cuartel Fragua nivel 2 Mando nivel 3
Academia militar Mando nivel 5
Mercado Comercio nivel 2
Taller de defensa Fragua nivel 6 Mando nivel 5
50
UNIDADES MILITARES
Infantería ligera Cuartel nivel 1 Academia militar nivel 2 Ataque nivel 2
Infantería pesada Cuartel nivel 5 Academia militar nivel 4 Ataque nivel 4
Caballería ligera Cuartel nivel 3 Academia militar nivel 4 Carga nivel 2
Caballería pesada Cuartel nivel 7 Academia militar nivel 7 Carga nivel 8
Arquero Cuartel nivel 4 Academia militar nivel 4 Alcance nivel 2
Saetero Cuartel nivel 6 Academia militar nivel 7 Alcance nivel 8
Dragón Cuartel nivel 12 Academia militar nivel 12 Asalto nivel 6
Espía Cuartel nivel 4 Academia militar nivel 4 Velocidad nivel 4
Convoy Cuartel nivel 2 Academia militar nivel 4 Velocidad nivel 4
UNIDADES DEFENSIVAS
Lanceros Taller de defensa nivel 2 Academia militar nivel 4 Defensa nivel 1
Piqueros Taller de defensa nivel 4 Academia militar nivel 6 Defensa nivel 4
Ballesteros Taller de defensa nivel 6 Academia militar nivel 6 Defensa nivel 6
Calderos de aceite Taller de defensa nivel 6 Academia militar nivel 7 Defensa nivel 8
Balistas Taller de defensa nivel 12 Academia militar nivel 12 Defensa nivel 10
WarBattle
51
3.Modelo de dominio
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.
52
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 e-mail 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.
WarBattle
53
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.
54
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
WarBattle
55
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.
56
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.
WarBattle
57
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.
58
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
WarBattle
59
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.
60
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.
WarBattle
61
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.
62
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
WarBattle
63
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.
64
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.
WarBattle
65
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.
66
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.
WarBattle
67
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.
68
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.
WarBattle
69
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.
70
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:
WarBattle
71
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.
72
- Defensa bloqueada: esta entidad recoge la información necesaria para conocer los requisitos necesarios para que una unidad defensiva sea desbloqueada.
WarBattle
73
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
74
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:
WarBattle
75
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.
76
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.
WarBattle
77
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.
78
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
WarBattle
79
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.
80
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. - Habilidad pendiente: reúne la información necesaria para saber:
WarBattle
81
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.
82
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.
WarBattle
83
o Número de unidades defensivas pendientes de construcción. - 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.
84
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:
WarBattle
85
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.
86
4.Análisis de los casos de uso
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.
WarBattle
87
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:
Jugador
Registrar 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.
88
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
WarBattle
89
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.
90
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
WarBattle
91
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.
92
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:
Jugador
Ver información
aldea
Cambiar aldea
Ver mensajes
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.
WarBattle
93
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
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
95
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
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
97
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
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
99
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
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
101
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
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
103
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:
Jugador
Ver producción de
una aldea
Ver productor
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.
104
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
WarBattle
105
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
-
106
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
WarBattle
107
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.
108
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”
WarBattle
109
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
-
110
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:
Jugador
Ver edificios
Ver información de
un edificio
Aumentar de nivel
un edificio
Acceder al cuartel
Acceder a la
academia militar
Acceder a la
biblioteca
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.
WarBattle
111
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
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
113
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
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
115
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
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
117
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
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
119
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
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
121
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
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
123
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
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
125
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:
Jugador
Ver información de
una unidad militar
Construir unidades
militares
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.
126
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
WarBattle
127
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
-
128
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”
WarBattle
129
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
-
130
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
WarBattle
131
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
-
132
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:
Jugador
Ver información de
una unidad defensiva
Construir unidades
defensivas
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.
WarBattle
133
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
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
135
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”
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
137
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
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
139
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:
Jugador
Ver ciencias del
jugador
Ver información
sobre una ciencia
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.
140
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
WarBattle
141
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
-
142
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
WarBattle
143
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.
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
145
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
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
147
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:
Jugador
Ver habilidades
militares del jugador
Ver información sobre
una habilidad militar
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.
148
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
WarBattle
149
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
-
150
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
WarBattle
151
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.
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
153
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
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
155
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:
Jugador
Ver mapa
Ver casilla
Cambiar tierra
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.
156
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
WarBattle
157
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
-
158
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
WarBattle
159
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
-
160
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
WarBattle
161
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
-
162
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
WarBattle
163
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
-
164
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
WarBattle
165
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
-
166
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:
Jugador
Ver misiones
activas
Crear misión
Ver tiempo de
duración de un viaje
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.
WarBattle
167
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
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
169
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
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
171
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
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
173
5.Problemas y errores
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.
174
- 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.
WarBattle
175
6.Conclusiones
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.
176
WarBattle
177
CAPÍTULO 4
Diseño
178
1.Introducción 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.
WarBattle
179
- 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.
180
2.Arquitectura lógica
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-vista-
controlador). 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
WarBattle
181
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.
182
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
WarBattle
183
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:
184
Figura 4.1.4: Estructura del módulo controlador
WarBattle
185
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
186
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.
WarBattle
187
La estructura del módulo Motor se resume en la siguiente imagen:
Figura 4.1.6: Estructura del módulo motor
188
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
WarBattle
189
3.Diseño de la base de datos
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.
190
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:
- 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
191
3.1 Tipos de elementos
3.2 Costes y producción
192
3.3 Elementos de los usuarios
3.4 Elementos de las aldeas
WarBattle
193
3.5 Elementos de los productores y edificios
3.6 Elementos de las ciencias y habilidades
militares
194
3.7 Elementos de las unidades militares
3.8 Elementos de las unidades defensivas
WarBattle
195
3.9 Elementos de las misiones
3.10 Elementos del mapa
196
4.Algoritmos significativos
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.
WarBattle
197
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
198
A su vez, el proceso Alta aldea está compuesto de las siguientes
funciones:
ALTA
RECURSOS
ALTA EDIFICIOS
ALTA UNIDADES
BLOQUEADAS
ALTA
PRODUCTORES
ALTA EDIFICIOS
BLOQUEADOS
ALTA DEFENSAS
BLOQUEADAS
WarBattle
199
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)
GestorEdificiosaltaEdificios(aldea)
GestorProductores
altaProductores(aldea)
GestorUnidades
altaUnidadesBloqueadas(aldea)
GestorDefensas
altaDefensasBloqueadas(aldea)
FinTransaccion(conexion)
200
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:
WarBattle
201
FIN
TRANSACCION
ACTUALIZACION
RECURSOS
ACTUALIZACION
DEFENSAS
ACTUALIZACION
UNIDADES
ACTUALIZACION
HABILIDADES
ACTUALIZACION
CIENCIAS
ACTUALIZACION
EDIFICIOS
ACTUALIZACION
MISIONES
VUELTA
ACTUALIZACION
MISIONES IDA
ACTUALIZACION
EXTERNA
INICIO
TRANSICION
202
A continuación se realizarán los diagramas de flujo que explican el
funcionamiento de cada proceso hijo:
Actualización externa
COMPROBACION
MISIONES
ENTRANTES
¿Hay
misiones?
¿Hora actual <
hora destino?
ACTUALIZACION
HASTA HORA
DESTINO
EJECUTAR
MISION
ENTRANTE
¿Más
misiones?
si
si
si
no
no
no
WarBattle
203
Actualización misiones ida
COMPROBAR
MISIONES
PENDIENTES
¿Había?
COMPROBAR
FINALIZACION
¿Finalizada?
COMPROBAR
TIPO DE MISION
Tipo
COMPROBAR
POSICION
DESTINO
¿Libre?
ALTA ALDEA
BAJA MISION
ACTUALIZAR
DESTINO
REALIZAR
MISION
PREPARAR
VUELTA
¿Más
misiones?
sino
no si
colonizar
otro
nosi
si
no
204
Actualización misiones vuelta
COMPROBAR
HORA VUELTA
¿Ha vuelto?
ACTUALIZAR
RECURSOS
ACTUALIZAR
TROPAS
BORRAR MISION
no si
WarBattle
205
Actualización edificios
COMPROBACION
EDIFICIOS
PENDIENTES
¿Hay?
COMPROBACION
FINALIZACION
¿Finalizado?
ACTUALIZA
EDIFICIO
COMPROBACION
DE
DESBLOQUEOS
¿Desbloquea?
ELIMINA
BLOQUEO
¿Elemento
desbloqueado?
ALTA ELEMENTO
BLOQUEADO
no si
no si
no si
si
no
206
Actualización ciencias
COMPROBAR
BIBLIOTECAS
PENDIENTES
¿Hay?
COMPROBAR
FINALIZACION
¿Finalizado?AUMENTAR
NIVEL
COMPROBACION
DESBLOQUEOS
¿Desbloquea?
ALTA CIENCIA
BAJA BLOQUEO
CIENCIA
COMPROBACION
CIENCIA
PENDIENTE
¿Hay?COMPROBAR
FINALIZACION
¿Finalizado?
AUMENTAR
NIVEL
COMPROBACION
DESBLOQUEOS
¿Desbloquea?
ALTA ELEMENTO
BLOQUEADO
BAJA BLOQUEO
si
si
si
si
si
si
no
no
no
no
no
no
Actualización habilidades
WarBattle
207
COMPROBAR
ACADEMIAS
PENDIENTES
¿Hay?
COMPROBAR
FINALIZACION
¿Finalizado?AUMENTAR
NIVEL
COMPROBACION
DESBLOQUEOS
¿Desbloquea?
ALTA HABILIDAD
BAJA BLOQUEO
HABILIDAD
COMPROBACION
HABILIDAD
PENDIENTE
¿Hay?COMPROBAR
FINALIZACION
¿Finalizado?
AUMENTAR
NIVEL
COMPROBACION
DESBLOQUEOS
¿Desbloquea?
ALTA ELEMENTO
BLOQUEADO
BAJA BLOQUEO
si
si
si
si
si
si
no
no
no
no
no
no
208
Actualización unidades
COMPROBACION
UNIDADES
PENDIENTES
¿Pendientes?
COMPROBACION
FINALIZACION
ALTA UNIDADES
ASIGNACION
EJERCITO
sino
Actualización defensas
COMPROBACION
DEFENSAS
PENDIENTES
¿Pendientes?
COMPROBACION
FINALIZACION
ALTA DEFENSAS
ASIGNACION
ALDEA
sino
WarBattle
209
Actualización recursos
COMPROBACION
PRODUCTOR
PENDIENTE
¿Hay?
COMPROBACION
FINALIZACION
¿Finalizado?
CALCULO
UNIDADES
PRODUCIDAS
EXTRACCION
DATOS
ANTERIORES
CALCULO
PRODUCCION
HASTA
CONSTRUCCION
CALCULO
PRODUCCION
NUEVA
ACTUALIZACION
UNIDADES
si
si
no
no
210
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)
WarBattle
211
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?
ACTUALIZAR
RECURSOS
si
no
Este algoritmo se lleva a cabo en la clase GestorUnidades del módulo
DAO, por eso no se mostrará el diagrama de secuencia pertinente.
212
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?
AJUSTE
UNIDADES
COMPROBACION
RECURSOS
DISPONIBLES
¿Menos
disponibles que
solicitadas?
AJUSTE
RECURSOS
¿Mision ==
colonizar ||
espionaje?
COMPROBACION
CONVOY O
ESPIA EN
UNIDADES
¿Está?
COMPROBAR
OTRAS
POSIBLES
RESTRICCIONES
¿Puede?
ACTUALIZAR
UNIDADES Y
RECURSOS EN
ALDEA
ALTA MISION
si
si
no
si
si
si
no
no
no
no
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.
WarBattle
213
5.Problemas y errores
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.
214
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.
WarBattle
215
6.Conclusiones
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.
216
WarBattle
217
CAPÍTULO 5
Trabajo futuro
218
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.
WarBattle
219
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.
220
WarBattle
221
CAPÍTULO 6
Evaluación económica
222
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
HORAS TOTALES 700 horas
PRESUPUESTO TOTAL 32.950 €
WarBattle
223
CAPÍTULO 7
Bibliografía
224
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”.
WarBattle
225
ANEXO A
Manual de usuario
226
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.
WarBattle
227
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.
228
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.
WarBattle
229
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.
230
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.
WarBattle
231
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.
232
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.
WarBattle
233
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.
234
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.
WarBattle
235
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.
236
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.