Download VIDEOJUEGO DE ESTRATEGIA PARA NAVEGADORES WEB EN

Document related concepts

Lord of Ultima wikipedia , lookup

Ikariam wikipedia , lookup

Age of Empires: Castle Siege wikipedia , lookup

OGame wikipedia , lookup

Age of Empires II: The Age of Kings wikipedia , lookup

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