Informe Metodos De Programacion Usach, DIINF WAR
117
UNIVERSIDAD DE SANTIAGO DE CHILE FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA EN INFORMÁTICA Santiago de Chile 1/2015
-
Upload
arthur-kevin-pena-lozano -
Category
Documents
-
view
259 -
download
5
description
informe realizado durante el curso de metodos de programacion en la universidad de santiago de chile
Transcript of Informe Metodos De Programacion Usach, DIINF WAR
PROYECTO MÉTODOS DE
PROGRAMACIÓN
Laboratorio L-3
Entrega N°4
Integrantes: - Pablo Cáceres Luzanto
- Juan Pablo Rojas
- Arthur Peña Lozano
Profesor : Manuel Manríquez
Ayudante : Nelson Jerez
Santiago de Chile
1/2015
UNIVERSIDAD DE SANTIAGO DE CHILE
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA EN INFORMÁTICA
ÍNDICE DE CONTENIDOS
CAPÍTULO 1. Introducción..............................................................................1
1.1 MARCO TEÓRICO............................................................................................2
1.1.1 División en sub problemas...........................................................................2
1.1.2 División y conquista.....................................................................................2
1.1.3 Similitud de problemas.................................................................................3
1.1.4 Búsqueda en espacio de soluciones..............................................................4
1.1.5 Búsqueda en espacio de estados...................................................................4
1.1.6 Programación orientada a objetos (POO).....................................................5
1.1.7 Lenguaje Modelado Unificado (UML)........................................................5
1.1.8 Caso de uso...................................................................................................6
1.1.9 Diagrama de Clases......................................................................................6
1.1.10 Diagrama de secuencia.................................................................................7
1.1.11 Arquitectura de Software.............................................................................8
1.1.12 Arquitectura MVC........................................................................................8
1.1.13 Base de datos................................................................................................8
1.1.14 Base de datos relacionales............................................................................9
CAPÍTULO 2. Descripción del problema.......................................................11
CAPÍTULO 3. Descripción de la solución......................................................13
3.1 TERRENO.........................................................................................................16
3.1.1 Tablero con Terrenos Predeterminados......................................................18
3.1.2 Tablero con Terrenos Aleatorios................................................................19
3.1.3 Sistema informa Porcentaje de Defensa del terreno...................................21
3.1.4 Sistema permite cambiar valor de oro proporcionado por Kioskos...........21
3.2 JUEGO...............................................................................................................22
3.2.1 Personajes...................................................................................................22
3.2.2 Juego Jugador.............................................................................................24
3.2.3 Juego CPU..................................................................................................27
3.2.4 Juego general (CPU y Jugador)..................................................................29
3.2.5 Enfrentamientos.........................................................................................31
3.3 DESARROLLO TORNEO................................................................................32
3.3.1 Torneo entre computadoras:.......................................................................32
3.3.2 Torneo entre usuarios y computadoras.......................................................34
3.4 REGISTRO........................................................................................................34
3.4.1 Ingreso de Usuario.....................................................................................35
3.4.2 Registro de partidas....................................................................................36
3.4.3 Registro actividades de cada usuario en la aplicación...............................36
CAPÍTULO 4. Diseño de la aplicación............................................................37
4.1 Diagrama de clases............................................................................................38
4.1.1 Unidad........................................................................................................39
4.1.2 Equipo........................................................................................................39
4.1.3 Batalla.........................................................................................................39
4.1.4 Casilla.........................................................................................................40
4.2 DS Mover unidad...............................................................................................40
4.3 DS Asignar naturaleza.......................................................................................42
4.4 DS PAUSAR Y REANUDAR PARTIDA........................................................44
4.5 DS Batalla entre dos jugadores..........................................................................45
4.5.1 Inicio...........................................................................................................45
4.5.2 En juego......................................................................................................46
4.5.3 Fin del juego...............................................................................................46
4.6 DS Pago Mantención.........................................................................................47
4.7 DS registro partida.............................................................................................48
4.8 DS Reclutamiento..............................................................................................50
4.9 DS creacion y Ejecucion torneo........................................................................51
4.10 DS Ataque..........................................................................................................53
4.11 DS General........................................................................................................55
CAPÍTULO 5. Descripción de la aplicación...................................................58
5.1 Vistas.................................................................................................................58
5.1.1 Vista Menú Inicial......................................................................................58
5.1.2 Vista Menú Registro...................................................................................59
5.1.3 Vista Menú Principal..................................................................................60
5.1.4 Vista Configurar Partida.............................................................................61
5.1.5 Vista Tablero..............................................................................................62
5.2 Modelos.............................................................................................................63
5.3 Controladores.....................................................................................................63
CAPÍTULO 6. Conclusiones............................................................................67
CAPÍTULO 7. Bibliografía..............................................................................69
AXEXO A: Tiempos utilizados.........................................................................70
ÍNDICE DE FIGURAS
Figura 1: Tablero de Juego...................................................................................16
Figura 2: Estado inicial tablero Crear Tablero Aleatorio.....................................19
Figura 3: Ejemplo Estado Final Crear Tablero Aleatorio....................................20
Figura 4: Estado Inicial Tablero, Movimiento Unidad........................................25
Figura 5: Estado Final Tablero, Movimiento Unidad..........................................25
Figura 6: Representación de un Estado y Estado Inicial de Torneo....................33
Figura 7: Representación estado Final de Torneo................................................33
Figura 8: Diagrama de clases...............................................................................38
Figura 9: DS Mover Unidad.................................................................................40
Figura 10: DS Asignar Naturaleza.......................................................................42
Figura 11: DS Pausar y Reanudar Partida............................................................44
Figura 12: DS Batalla entre dos jugadores...........................................................45
Figura 13: DS Pago Mantención..........................................................................47
Figura 14: DS Registro Partida.............................................................................48
Figura 15: DS Reclutamiento...............................................................................50
Figura 16: DS Creación y ejecución Torneo........................................................51
Figura 17: DS Ataque...........................................................................................53
Figura 18: DS General..........................................................................................55
Figura 19: Vista Menú Inicial...............................................................................58
Figura 20: Vista Menú Registro...........................................................................59
Figura 21: Vista Menú Principal..........................................................................60
Figura 22: Vista Configurar Partida.....................................................................61
Figura 23: Vista Tablero (sin restricciones de terreno)........................................62
ÍNDICE DE TABLAS
Tabla 1: Funcionalidades a Cumplir.....................................................................13
Tabla 2: Porcentaje de Defensa de Terrenos.......................................................16
Tabla 3: Estadísticas por Unidad .........................................................................22
Tabla 4: Características de la Naturaleza.............................................................23
Tabla 5: Opciones de As Táctico..........................................................................31
Tabla 6: Representación Registro de Usuarios.....................................................35
Tabla 7: Representación Registros de Partidas....................................................35
Tabla 8: Actividades y tiempos utilizado HITO 1................................................70
Tabla 9: Actividades y tiempos utilizados HITO 2..............................................71
Tabla 10: Actividades y tiempos utilizados HITO 4............................................72
CAPÍTULO 1. INTRODUCCIÓN
Durante una tarde de Marzo en la Universidad de Santiago de Chile, específicamente en
el Departamento de Ingeniería Informática. Los profesores durante su tiempo de
descanso observaron las publicaciones de los nuevos alumnos en los foros, en dónde
realizaban recomendaciones y comentarios sobre algunos profesores. Tornándose en una
disputa entre ellos, los profesores, donde se cuestionaron ¿Qué profesor es el favorito de
los niños? La duda llevó al punto de una ardua lucha; tiempo después se logró instanciar
una tregua, la cual fue encomendada a los alumnos que cursan Métodos de
Programación durante el primer semestre del año 2015.De esta forma, se decide realizar
una Aplicación de Entretenimiento, es decir un juego, el cual contemplaba
características de un estilo RPG (Role Playing Game, en español Juego de rol)1.
Este juego trata principalmente de que en un mapa se encuentran dos profesores, los
cuales luchan por derrotar al otro mediante el uso de sus aliados, los cuales pueden ser
alumnos, ayudantes, etc. La forma de vencer es cuando se derrota al profesor enemigo.
Con este tipo de batallas se puede realizar un torneo en el cual el ganador, por supuesto,
será el “Profesor favorito de los niños”.
Por lo tanto se ha determinado que el objetivo principal de esta contienda es realizar la
aplicación (o juego) en pos de solucionar la problemática actual en el Departamento de
Informática de la Universidad de Santiago de Chile.
Este documento se encuentra dividido en 6 capítulos, empezando con la Introducción al
problema, permitiendo realizar una vista general al proyecto junto a definiciones que
previamente se deben manejar. Para luego, en el siguiente capítulo, Descripción del
Problema, desglosar cada uno de los puntos de la problemática general.
1 Un juego de rol es un juego donde los jugadores asumen el rol
de personajes imaginarios a lo largo de una historia o trama. Cada personaje realiza
acciones o movimientos en una cantidad o tiempo específicos.
1
Luego, se aborda la Descripción de la solución, donde se detallan los métodos de
resolución de problemas que se utilizarán para cada funcionalidad, requerimiento o
situación que surja durante el proyecto.
A continuación, en el cuarto capítulo, se procede a detallar y explicar los distintos
diagramas de clases y secuencias necesarios para el diseño de la aplicación.
En el siguiente capítulo (conclusiones) se habla de las distintas complicaciones que
surgieron durante el desarrollo de esta etapa del proyecto, los temas y áreas que se
trataron y los que van a tratarse en la siguiente etapa del proyecto.
Finalmente, en el último capítulo se referencian todas las fuentes de información a las
que se concurrió para llevar a cabo esta etapa del proyecto.
1.1 MARCO TEÓRICO
1.1.1 División en sub problemas
Consiste en sub dividir un problema en objetivos manejables, cada sub problema a su
vez puede ser subdividido en muchos más sub problemas de tal forma en que cada uno
de estos sea más manejable en relación al problema inicial.
La solución final en este tipo de resolución de problemas se compone en base a cada una
de las soluciones de los sub problemas creados a partir del problema inicial.
1.1.2 División y conquista
Consiste en expresar la solución a un problema en instancias más “pequeñas” del mismo
problema, hasta que se vuelven suficientemente simples como para resolverlas
directamente.
Para aplicar este método de resolución de problemas se debe dividir el problema inicial
en dos (o más) sub problemas. Después de esto se debe resolver cada problema de forma
independiente y finalmente se combinan (si así se desea) las soluciones obtenidas para
obtener la solución final al problema inicial.
2
Una característica que diferencia ambos métodos de resolución mencionados
anteriormente es que en el primero, los sub problemas asociados al problema inicial no
necesariamente deben resolverse de la misma cada uno de ellos. Mientras que en el
segundo los sub problemas a conquistar se resuelven de la misma forma cada uno de
ellos.
1.1.3 Similitud de problemas
Problemas nuevos pueden ser resueltos con soluciones (algoritmos) ya conocidos. Se
pueden reconocer dos tipos de similitudes de problemas:
1.1.3.1 Similitud débil
Una vez identificada la solución ya conocida que se debe aplicar al problema dado,
basta con aplicar ciertos cambios en el algoritmo de la solución para obtener la
solución adecuada al problema.
1.1.3.1 Similitud fuerte
Esta similitud se da cuando dos o más problemas poseen un enunciado distinto pero que
tienen la misma estructura. En este caso se modifican datos y operaciones (unidades de
medida, decimales, enteros, flotantes, strings, etc.) en los valores de entradas y/o
salidas. La similitud es fuerte cuando dos problemas son, en el fondo, el mismo
problema.
Cabe destacar que puede haber dos problemas que son exactamente iguales y no se
necesita realizar ninguna modificación a la solución ya existente. Este caso no
corresponde a ninguna de las similitudes mencionadas anteriormente.
1.1.4 Búsqueda en espacio de soluciones
En este método de resolución de problemas, los problemas vienen definidos por una
solución y un conjunto de restricciones que ésta debe cumplir.
Entiéndase por espacio de soluciones, el conjunto de todas las posibles respuestas que
cumplen a la forma general de la solución. Este conjunto se puede ir acotando de tal
3
forma que solo queden soluciones que cumplan con las restricciones impuestas por el
problema.
Así, se obtendrá un pequeño conjunto con las posibles respuestas que se tienen al
problema. Finalmente, si es que existe algún criterio de optimización, éste se aplica y se
entregan las mejores soluciones posibles al problema.
1.1.5 Búsqueda en espacio de estados
El tipo de problema al cual se le aplica este método de resolución se caracteriza por estar
definido de la forma de una situación inicial la cual debe ir variando con el paso del
tiempo para así llegar a una situación final.
Es importante identificar cual es el estado inicial y el estado final (objetivo) de nuestro
problema, así como también las acciones que se deben realizar para llegar al estado
objetivo. Cada una de estas características define lo que se conoce como espacio de
estados.
De esta forma una solución corresponde a una secuencia de acciones que irán desde el
estado inicial al objetivo. Para realizar esto se deben utilizar políticas de búsqueda y
criterios de parada para concluir que no hay solución.
En este caso el tipo de política que se usa se denomina búsqueda en anchura, el cual
consiste en aplicar todas las acciones a un estado antes de aplicar las acciones a los
estados que se han generado.
Una diferencia importante entre búsqueda en espacio de estados y soluciones, es que en
el primer método se entrega un conjunto con las mejores soluciones posible al problema.
Mientras que en el segundo método se entrega solo una solución (estado objetivo).
1.1.6 Programación orientada a objetos (POO)
La programación orientada a objetos, es una forma de modelar un problema de tal
manera que la representación de los actores que están dentro de este conflicto, sean
definidos como clases y objetos los cuales contiene características y acciones propias, en
4
donde luego establecer relaciones entre estos se puede implementar una solución a
través de un lenguaje de programación. Definiremos algunos conceptos que tienen que
ver directamente con el POO:
1.1.6.1 Clase: Es un modelo contiene características y comportamientos de algún tipo
objeto concreto.
1.1.6.2 Objeto: Elemento que contiene propiedades (atributos) y también definen
comportamientos (métodos) propios.
1.1.6.3 Relaciones: Indica la relación entre clases y objetos.
1.1.6.4 Herencia: relación que permite clasificar elementos según su tipo en los cuales
se puede ir estableciendo jerarquías (de lo más general a lo más específico),
cada uno de estos elementos obtiene ciertas características de su instancia más
general.
1.1.7 Lenguaje Modelado Unificado (UML)
Permite estructurar el desarrollo y funcionamiento del software, de modo que sea
entendible para todo aquel que quiera saber qué es lo que hace y como lo hace
especialmente como se relaciona cada uno de los componentes que permiten el
funcionamiento del software, este lenguaje promueve el orden y legibilidad de la
resolución de un problema mediante la programación, para que así la descripción de un
software sea entendible.
1.1.8 Caso de uso
Son acciones detalladas mediante una secuencia de pasos entre el actor (rol que posee el
usuario dentro del sistema, este puede tener más de un rol) y el sistema, representan la
interacción detallada en donde se indica indican la forma, el tipo y el orden de la
relación entre el usuario y sistema, cada uno posee especificaciones: identificador(id),
nombre, resumen(que hace), actores, precondiciones(que se necesita para hacer la
acción), descripción, postcondiciones(estado final del CU) y excepciones. Para
relacionar casos de usos se destacan los siguientes conceptos:
5
1.1.8.1 Inclusión: Casos de uso que utilizan otros casos de uso para cumplir su
objetivo.
1.1.8.2 Extensión: Casos de uso que se extienden “nacen” del caso de uso principal.
1.1.9 Diagrama de Clases
El diagrama de clases es una representación del problema mediante el UML, en donde se
indican las clases necesarias para resolver el problema, en donde estas se generan
mediante el procedimiento de: Buscar sustantivos relevantes en el problemas, entidades
del mundo real y sustantivos que no puedan ser una descripción o propiedad, las clases
en este diagrama llevan consigo sus respectivos métodos y atributos y sus respectivas
relaciones entre clases adyacentes y respectivos objetos, la representación de cada una
de las partes que conforman este diagrama se representa:
1. Clase: Siendo la entidad principal del diagrama se representa mediante un rectángulo
el cual posee el nombre, atributos y métodos.
2. Relaciones: Son las formas en las que se relacionan las clases, existen distintos tipos:
2.1. Generalización: La clase posee métodos y atributos de una clase superior
(padre), se representa mediante una flecha de punta blanca, la cual siempre
apunta al padre.
2.2. Agregación: se utilizan para modelar clases más complejas, dentro de esto se
encuentra:
2.2.1. Por valor: indica que el tiempo de vida del objeto está dependiendo del tiempo
de vida del objeto que lo incluye (composición), para representarlo se utiliza un
rombo relleno.
2.2.2. Por referencia: indica una relación en la cual los tiempos de vida de los objetos
que interactúan son independientes, se representa por un rombo relleno.
2.3. Asociación: asocia objetos que colaboran entre si y los tiempos de vida son
independiente, se representa mediante una línea.
6
2.4. Dependencia: indica la dependencia entre clases, apunta al objeto condicionado
y se representa por una flecha con línea segmentada.
3. Cardinalidad: indica la cantidad de elementos que están relacionados entre las clases,
se representan de la siguiente manera:
3.1. Uno a uno (1 1), uno a muchos (1…*), cero a muchos (0…*), número fijo (n)
1.1.10 Diagrama de secuencia
Los diagramas de secuencias muestran una situación en particular de nuestra aplicación,
en la cual se representa como los elementos interactúan entre sí para llevar a cabo una
acción en particular. Contiene elementos como
1. Objetos: Son elementos que interactúan dentro de la acción representada en el
diagrama de secuencia.
2. Mensajes: Estos permiten la comunicación entre objetos para así permitir que la
acción avance, también se pueden realizar auto mensajes.
2.1. Mensaje Simple: Muestra una transferencia de control de un objeto a otro.
2.2. Mensaje Sincrónico: son aquellos mensajes que son enviados con el fin de
recibir una respuesta, con esto el objeto inicial que ha enviado el mensaje pueda
seguir ejecutando su trabajo.
2.3. Mensaje Asincrónico: son aquellos mensajes que son enviados sin esperar una
respuesta a partir de estos.
3. Tiempo: se representa de forma vertical con una línea segmentada que sale de los
objetos.
1.1.11 Arquitectura de Software
Es un conjunto de patrones que permiten a un conjunto de actores (analistas,
programadores, etc.) en un proyecto de desarrollo de un software trabajar bajo un mismo
hilo conductor o línea de trabajo con el fin de cubrir todos los objetivos y restricciones
de una aplicación. La arquitectura de software es considerada la parte más importante a
7
la hora de diseñar una aplicación, puesto que establece la estructura, funcionamiento e
interacción entre las partes de un software.
1.1.12 Arquitectura MVC
Este patrón de arquitectura se utiliza, por lo general, para implementar aplicaciones que
requieran el uso de interacciones con el usuario. Se utiliza con el fin de separar
conceptos y funciones de manera ordenada, potenciando de esta forma, la facilidad de
mantenimiento y reutilización de código.
Como se menciona en el párrafo anterior, el fundamento en el cual se basa este patrón es
la separación del código en tres capas diferentes, acotadas por sus respectivas funciones,
en lo que se llaman Modelos, Vistas y Controladores (MVC).
1.1.13 Base de datos
Se puede definir como una colección de datos y objetos que tienen un propósito
definido. Desde esta perspectiva es que, una base de datos puede ser cualquier tipo de
colección de información.
Para este proyecto en específico, se hará un enfoque en un tipo especial de base de datos,
denominadas Bases de datos relacionales.
1.1.14 Base de datos relacionales
Se caracteriza por almacenar información en tablas. Las tablas poseen un conjunto de
columnas, donde cada columna posee un tipo de dato definido. Estas tablas pueden
relacionarse entre sí. Su principal objetivo consta de representar la información y las
relaciones existentes, para que de este modo la información contenida en la base de
datos sea independiente de cualquier tipo de aplicación.
Las aplicaciones realizan 4 operaciones básicas sobre las base de datos relacionales.
1. Crear (CREATE): Crear una nueva base de datos o un nuevo registro (insert-
create).
2. Leer (READ): Leer Información de la base de datos (select).
8
3. Actualizar (UPDATE): Actualizar algún registro (o un conjunto de registros) en
la base de datos (update).
4. Borrar (DELETE): Borrar una base de datos, tabla o registro(s) (delete-drop).
9
CAPÍTULO 2. DESCRIPCIÓN DEL PROBLEMA
El Departamento de Informática presenta un grave problema de convivencia que afecta
desde docentes a alumnado nuevo del departamento, este problema radica en la
interrogante ¿Quién es el profesor favorito?
Ante ello se encuentran, en medio de la discusión, sujetos íconos del departamento como
por ejemplo:
-Coordinadores de ayudantes - Ayudantes
-Alumnos - Coordinadora docente (Pame)
-Profesores - Alumnos de nivel Superior
-Cachorros
Cada sujeto tiene roles diferentes tanto en el departamento como en la Universidad, por
lo que su desempeño en la contienda varía según sus características.
Existen datos que el tema se discute en diversos sectores de la Universidad de Santiago
de Chile, llegando incluso al sector más lejano del departamento. Los sectores en los que
se ha constatado hechos son:
- Pastos - Foro
- EAO - Laboratorios
- Kioscos - Calle
- CiteCamp - DIINF
- Sherwood - Casitas
A medida que aumenta la polémica los sujetos obtienen más conocimientos respecto al
tema pero no llegan conceso alguno generando violencia entre ellos.
11
CAPÍTULO 3. DESCRIPCIÓN DE LA SOLUCIÓN
Siempre considerando que el problema gira en torno a la pregunta ¿Quién ese el
profesor favorito de los niños? Luego de un análisis exhaustivo:
Con lo expuesto del problema, de naturaleza bélica, y la cantidad de sujetos
implicados en el asunto y la variedad de entornos en que se desarrolla. En vista y
consideración que la mejor manera de decidir un enfrentamiento entre informáticos,
amantes de los juegos computacionales, se decide realizar una aplicación la cual
simule las batallas que se estaban realizando para evitar casos que perjudiquen a la
integridad física de las personas. Esto a partir de las mismas demandas de los
interesados las cuales se detalla a continuación:
Tabla 1: Funcionalidades a Cumplir
N°Requerimient
o FuncionalContenido
Sub
Sección
1Sistema debe permitir el enfrentamiento de dos
Grupos.Juego
1 1.aDebe permitir enfrentamiento entre dos
jugadoresJuego
2 1.bDebe permitir el enfrentamiento entre un
jugador y el computadorJuego
3 1.cDebe permitir la simulación completa de una
batalla, es decir CPU vs CPUJuego
4 2Sistema debe permitir generar torneos de 8
participantes con eliminación directaTorneo
3 Terreno de batalla Terreno
5 3.aSistema debe contar con al menos 3 mapas
predeterminadosTerreno
6 3.bSistema debe tener la posibilidad de generar
mapas aleatoriamente con distintos terrenos.Terreno
7 3.cSistema debe mostrar de alguna forma el
porcentaje de defensa del terreno.Terreno
13
8 3.d Debe darse una habilidad al terreno EAO Terreno
4Sistema debe llevar un registro de las
actividades de cada usuario en la aplicación.
Registro
Historial
9 4.aSistema solicitará al jugador identificarse antes
de comenzar la partida.
Registro
Usuario
10 4.b
Sistema llevará un registro de las partidas
ganadas y perdidas de cada jugador incluyendo
CPU, el cual podrá ser consultado en la
aplicación.
Registro
Historial
5 Identidad de PersonajesPersonajes
Juego
11 5.aCada personaje tendrá características,
habilidades y naturaleza para cada tipo.
Personajes
Juego
12 5.bLos personajes tienen capacidad de subir de
nivel durante el juego
Personajes
Juego
13 5.cPersonajes tienen capacidad de desplazarse a lo
largo del Terreno según sus características.
Personajes
Juego
6 Se debe contar con un sistema de Combate Juego
14 6.a
Unidades tienen la capacidad de enfrentarse y
causar daño al enemigo. Considerando factores
como el terreno, características de unidad y
posicionamiento.
Personajes
Juego
15 6.bUnidad que ha sido atacada realizará un
contraataque después del ataque rival.
Personajes
Juego
16 7
Jugador tiene capacidad de reclutar unidades
según los requisitos, ya sea por costo en oro o
posiciones.
Usuario
Personajes
17 8Cada unidad requiere un costo de mantención
en oro.
Personajes
Juego
14
18 9Las unidades pueden ser curadas por una
habilidad aliada o efecto especial.
Personajes
Juego
10 Dinámica de juego Juego
19 10.aIniciando la partida cada jugador asigna puntos
al Profesor y Nombres a sus ataques
Usuario
Personajes
20 10.b
Iniciando la partida se puede modificar la
cantidad de oro por defecto en terrenos
Kioskos.
Terreno
21 10.cAl iniciar el juego, se solicita la cantidad de
Kioskos en la partida.
Usuario
Terreno
22 10.d
Usuario tiene la opción de utilizar una habilidad
llamada As Táctico luego de un tiempo
determinado.
Usuario
Juego
23 10.e Toda unidad nueva inicia en nivel 1. Juego
24 10.fCada jugador inicia con una cantidad de oro,
determinada en 3 valores.
Usuario
Juego
25 10.gDos unidades no pueden estar en la misma
casillasJuego
26 10.h
Se puede avanzar sobre una unidad aliada,
siempre y cuando la cantidad de movimientos
sean suficientes para alcanzar una casilla vacía.
Juego
27 10.iJugador puede escoger mover y atacar con una
unidad en el mismo turno en el orden que desee.
Usuario
Juego
28 10.j Unidades pueden atacar solo una vez por turno. Juego
29 10.k Incluir otra habilidad de As Táctico Juego
15
3.1 TERRENO
El tablero del juego se compone de casillas con un tamaño de 9x18 con una columna
de 5 casillas extra a cada costado, las cuales corresponden al laboratorio de cada uno
de los profesores, siendo la casilla central la que corresponde a la mesa del profesor.
A continuación se presenta una figura para que se entienda de mejor manera la idea
anterior.
Figura 1: Tablero de Juego2
En el mapa pueden existir distintos terrenos, los cuales poseen ciertas características
que los diferencian unos de otros. Junto a sus características, estos son:
Tabla 2: Porcentaje de Defensa de Terrenos
Terreno % Defensa Tamaño Característica Especial
Pastos 40% 1x1
Unidades ganan +2 de ataque en el terreno.
Jugador debe pagar 1 de oro por cada unidad que
se encuentre en el terreno.
EAO 50% 1x1 Unidad que pase por sobre este terreno acabara
sus movimientos inmediatamente por el turno.
2 -Extraído del enunciado del Proyecto 2015-1, página 5.
16
Al siguiente turno esta unidad posee un aura que
reduce la defensa de terreno de unidades
enemigas adyacentes (3x3) y puede desplazarse
normalmente.
Kiosko 60% 2x2
Debe existir al menos 2 en el mapa.
Puede ser controlada por una unidad si no tiene
dueño.
Si un equipo se coloca en un kiosco oponente,
sólo podrá obtener el control de éste teniendo
más unidades que el oponente en el terreno.
Al inicio del turno, del jugador que controle
kiosko, obtiene 5 de oro.
CiteCamp 50% 1x1
Unidades ubicadas en el terreno, al siguiente
turno obtendrán +1 en ataque y +1 en cantidad
de golpes. (No acumulable)
Sherwood NULO 1x1
Ninguna unidad puede ubicarse o pasar por este
tipo de terreno.
Existen 4 en el tablero.
Calle 0% 1x1
Terreno sin característica especial. Tiene
particularidad de ser de varios tipos de
materiales. Deben existir al menos 2 en caso de
existir.
Laboratorio 70% 3x2Debe existir al menos uno en el mapa
Puede ser controlada por una unidad si no tiene
dueño.
Si un equipo se coloca en un kiosco oponente,
sólo podrá obtener el control de éste teniendo
más unidades que el oponente en el terreno.
17
Cada equipo inicia en posesión de 1 laboratorio
Deben existir otros Laboratorios en el mapa sin
posesión de equipo alguno.
Foro 30% 1x1
Al inicio de cada turno el jugador debe pagar 1
de oro adicional por cada unidad que se
encuentre en este tipo de terreno.
DIINF 60% 1x1Similar al CiteCamp, pero su mejor es
instantánea.
Casitas 40% 1x1
Alumnos y Ayudantes regeneran +5HP, estando
ubicados sobre él, al inicio del turno del jugador
que lo posea.
3.1.1 Tablero con Terrenos Predeterminados
Para este problema se aplica Búsqueda en Espacio de Soluciones de tal manera que:
Forma Solución: Matriz de la misma dimensión que el tablero, es decir 9x18, en la
cual se describe el terreno de cada casilla del tablero. Siendo cada casillero de la
matriz “solución” el respectivo casillero de la matriz de “tablero”.
Restricciones: - Deben existir al menos 2 “Kioskos”
- Debe existir al menos 1 “Laboratorio”
- Debe haber 4 terrenos “Sherwood”
- Toda casilla debe tener 1 terreno asignado. (Sólo 1)
- Casillas con terreno de dimensión mayor a 1x1, deben tener
en sus cercanías otras casillas del mismo tipo de terreno.
Aplicando la forma correspondiente a lo descrito en la
dimensión del terreno.
- Si existe un casillero con terreno “Calle” debe existir al
menos uno más.
18
Optimizaciones: 1.- Razón de la suma de defensas de terreno entre la mitad de
campo (9x9) con la suma de la otra mitad igual a 1.
2.- Cantidad de Kioskos debe ser la cantidad definida por el
usuario anteriormente (considerando restricción, mínimo 2)
De esta forma se obtiene una gama de soluciones de tableros con terreno, sin ventajas
y desventajas para equipo algunos. De las cuáles el equipo desarrollador elegirá 3 a
gusto personal.
Estas soluciones se exhibirán al usuario como tipo de mapa predeterminado (1), (2) y
(3) o por algún nombre en especial alusivo a las condiciones del tablero con terreno.
3.1.2 Tablero con Terrenos Aleatorios
Ante las distintas dimensiones que presentan los terrenos se dividirá el procedimiento
de cada uno según su dimensión. Clasificando:
- Terrenos dimensión mayor a 1x1
- Terrenos dimensión 1x1 con restricciones de cantidad
3.1.2.1 Terrenos dimensión mayor a 1x1
Se aplicará el método de resolución de Búsqueda en espacio de Estados siendo:
Estado inicial: Matriz 9x18 sin detalles en cada espacio, visualizándose en blanco.Figura 2: Estado inicial tablero Crear Tablero Aleatorio
19
Estado final: Matriz 9x18 detallando el tipo de terreno (solo diferentes a 1x1) en
algunos espacios, la matriz debe contener la cantidad mínima o máxima de cada
terreno y haberse realizado el sorteo casilla a casilla.
Ejemplo:
Figura 3: Ejemplo Estado Final Crear Tablero Aleatorio
Conjunto de acciones:
- Por cada casilla vacía sortear el tipo de terreno que tendrá entre todos los
terrenos posibles (revisión realizada de izquierda a derecha, de arriba hacia
abajo):
-
o Si el terreno sorteado tiene una dimensión 1x1:
- Pasar a la casilla siguiente.
20
o Si el terreno elegido tiene dimensión diferente 1x1 y no ha cumplido
máximo:
- Situar el terreno en la casilla y situar terreno en las casillas aledañas hasta formar
la dimensión especificada, esto se realiza comprobando la existencia de casilla
en el orden hacia abajo, derecha, abajo-derecha, abajo-izquierda, izquierda,
arriba-derecha, arriba, arriba-izquierda.
- En caso de no poder situar el conjunto de casillas con el terreno respectivo,
anular operación. Y pasar a la siguiente casilla a sortear.
- Habiendo terminado la revisión casilla por casilla, si algún terreno con cantidad
mínima predefinida no se cumple, se realizará una búsqueda rápida de una
casilla que cumpla los requisitos para situar el terreno. En caso de ser más de
uno se realizará de la misma manera con los otros.
3.1.2.2 Terrenos dimensión 1x1
Similitud débil con respecto al punto 3.2.2.1, en este caso no es necesario comprobar
las casillas aledañas ya que la dimensión no lo requiere.
3.1.3 Sistema informa Porcentaje de Defensa del terreno
Se informará directamente a través del Sistema “Características del Terreno”, al
seleccionar alguna casilla, en una esquina de la aplicación.
3.1.4 Sistema permite cambiar valor de oro proporcionado por Kioskos
Sistema preguntará al usuario si desea cambiar la cantidad de oro predeterminada
otorgada al momento en que una unidad se encuentre sobre algún terreno Kiosko.
Este valor modificara sólo durante la partida la tabla de características de terreno.
21
3.2 JUEGO
En esta sección se da a conocer las soluciones correspondientes a todo lo necesario
para realizar una partida según el modo en que se estime conveniente, entre estas
están el enfrentamiento entre dos jugadores, enfrentamiento jugador contra CPU y la
modalidad de CPU versus CPU.
3.2.1 Personajes
En este juego existe una gran cantidad de personajes, los cuales poseen diversas
estadísticas que los hacen ser diferentes unos de otros y asimismo adquirir distintos
niveles de importancia dentro del juego, claramente estos personajes son las distintas
autoridades que son parte del DIINF como también alumnos en sus distintos niveles,
en la siguiente tabla se muestra los personajes participantes del juego con sus
respectivas estadísticas y dinámica dentro del juego.
Tabla 3: Estadísticas por Unidad 3
Personajes HP Movimientos Ataque Cantidad de golpes Rango
Coordinador
de
Ayudantes
35 2
6 3 Largo
2 2 Corto
Ayudante 50 37 3 Corto
9 2 Corto
Alumno 40 44 3 Medio
4 3 Corto
Pame 30 4 3 4 Medio
Profesor 75 3- 2 Corto
- 3 Medio
Alumno nivel
superior40 6
2 2 Corto
1 3 Medio
1 2 Largo
Cachorro 30 3 1 2 Corto
3-Extraído del enunciado del Proyecto 2015-1, página 4.
22
2 1 Medio
Donde:
Heal Point (HP): Tal como lo indica su nombre, corresponde a los puntos de salud de cada unidad. Estos se van agotando a medida que se recibe daño y recuperando a medida que transcurre el tiempo. Un personaje queda fuera de combate cuando su HP es menor o igual que 0.
Movimientos: Corresponde a la cantidad de casillas que se puede mover una
unidad en un turno.
Ataque: Es la fuerza con que golpea una unidad y equivale a la cantidad de
HP que se restará de la unidad defensora si el ataque se lleva a cabo de forma
correcta.
Cantidad de golpes: Número de veces que una unidad puede realizar ese
ataque por turno.
Rango: Longitud del ataque, puede ser corto, medio o largo.
Como en la gran mayoría de RPGs, los personajes tienen la capacidad de subir
niveles durante el juego. A medida que van luchando y derrotando a sus oponentes
tienden a ganar experiencia y así van mejorando sus habilidades.
Naturaleza: La naturaleza de cada personaje se adquiere cuando se llama al
personaje y se obtiene de manera aleatoria sólo una. Cabe destacar que cada
profesor puede escoger dos de las siguientes naturalezas: Estudioso, Normal,
Deportista o Incoherente. A continuación se describen éstas y otras
adicionales.
Tabla 4: Características de la Naturaleza
Carretero Disminuye en uno la cantidad de golpes
Normal No recibe ninguna característica especial
23
Estudioso Un punto más de ataque que el original
Incoherent
eAumenta en uno la cantidad de golpes
Deportista Permite avanzar un movimiento más que el original
Deprimido Disminuye en uno su ataque
Tortuga Disminuye en uno su cantidad de movimiento original
3.2.2 Juego Jugador
3.2.2.1 Movimiento de unidad
Se divide en dos subproblemas, calcular casillas alcanzables para mostrar a jugador y
cálculo de la vía más rápida para llegar a alguna casilla seleccionada (dentro de las
alcanzables).
1. Casillas Alcanzables
El jugador al decidir mover una unidad podrá observar el rango que esta se puede
mover para resolver esto se aplicará el método de resolución de problemas
"búsqueda en espacio de solución”.
Forma Solución:
{ Casilla[ i ][ j ] }
Restricciones:
- Límites del tablero
- Casillas ya ocupadas por unidades
- Casilla ocupada por aliado se salta, pero descuenta
movimiento de unidad de igual manera.
- Casillas Sherwood
- Disponibilidad de movimientos en la Unidad.
- Movimiento unidad a casillas aledañas
Salida:
Casillas a las que la unidad puede llegar.
24
2. Movimiento a casilla seleccionada
Al jugador, una vez elegida la casilla a desplazarse entre las válidas, se
mostrará la trayectoria de la unida en el desplazamiento. Para ello se
implementará Búsqueda en espacio de estados.
Estado inicial: Posición inicial de la unidad.
Ej:
Figura 4: Estado Inicial Tablero, Movimiento Unidad
Estado final: Posición objetivo de la unidad.
Ej:
Figura 5: Estado Final Tablero, Movimiento Unidad
Transiciones:
- Unidad se mueve hacia casilla cercana:
~ Mover: Arriba – Abajo – Izquierda – Derecha – Arriba Izquierda –
Arriba Derecha – Abajo Izquierda – Abajo Derecha
De esta forma obtendremos la trayectoria que recorrió la unidad para llegar de una
casilla a otra.
25
3.2.2.2 Reclutamiento
En cada turno el jugador tiene la capacidad de reclutar a las unidades que estime
conveniente las que aparecerán en el laboratorio destinado para ello “punto
respawn”, esto considerando las restricciones que supone la acción.
El jugador tiene la opción de elegir otro laboratorio en su control, en caso de poseer,
cambiando el “punto respawn”. Para ello se aplica algoritmo directo en el cual el
jugador nombra como “punto respawn” al laboratorio que seleccione.
Para esto se aplica búsqueda en espacio de soluciones para ofrecer al jugador las
posibilidades que tiene de reclutar considerando el oro actual.
Forma solución: {Unidad : costo}
Restricciones:
- Costo de la unidad no puede superar el oro actual del
jugador
- Unidad profesor se debe encontrar en el trono
Salida: Gama de unidades disponibles a reclutar
3.2.2.1 Atacar
Acción de iniciar un combate será verificado según el rango de la unidad atacante. Al
entrar en modo ataque la unidad, se mostrará el rango de ataque al jugador, siendo
capaz de elegir las unidades enemigas dentro del rango.
Para esto se emplea nuevamente Búsqueda en espacio de soluciones para obtener
las posibilidades validas donde el usuario podrá atacar.
Forma solución: { Unidad en casilla del tablero[x][y] – Rango del ataque}
Restricciones:
- Rango de ataque de la unidad
- Solo a unidades enemigas
Salida: Ataques posibles válidos especificando tipo de ataque
26
3.2.3 Juego CPU
Para resolver este problema se utiliza el método de resolución denominado “sub
división de problemas” para así dividir el problema en otros más simples de manejar
y una vez obtenida las soluciones a estos, poder unirlas para lograr una solución
adecuada y de acuerdo al problema.
El sistema se encargara automáticamente de:
3.2.3.1 Reclutamiento
El reclutamiento estará dado poniendo como prioridad el reclutamiento de la unidad
de mayor coste con la que se pueda pagar, para luego ir de la misma manera
reclutando unidades según los recursos que sobren.
La solución consta principalmente por un Método de recursión, en donde la
condición de borde será el costo de la unidad de menor valor, con esto se ira
haciendo adquisición de la unidad de mayor valor siguiendo de la misma manera con
los recursos sobrantes hasta llegar a la condición de borde
3.2.3.2 Asignación de puntos de habilidad
La asignación de puntos de habilidad está dada de una manera totalmente aleatoria.
3.2.3.3 Uso de habilidades, ataque y sanación
El uso de habilidades será asignada de manera tal que la mayoría de estas sean de
forma aleatoria (exceptuando el personaje Pame el cual tiene todos sus acciones por
defecto), por otro lado el ataque y sanación tendrá una acción automática según el
contacto establecido entre unidades.
3.2.3.4 Movimiento de personajes
El movimiento de unidades estará dado por un sistema de referencia el cual es el
profesor oponente, de esta forma se establecerá una probabilidad de movimientos
dada la restricción de 2 a 6 casillas alrededor de la unidad, sin contar el as táctico
(aumenta casillas de movimiento). “Búsqueda de espacios de solución” será la
27
manera correcta de llevar a cabo esta solución. En donde las soluciones serán todos
los movimientos que podría hacer la unidad dada la restricción de celdas a su
alrededor, la solución será escogida mediante el porcentaje de probabilidad de
movimiento:
Forma soluciones:{vector} ej: 6 i+6 j
Restricciones:
- Movimientos entre 2 a 6 casillas dependiendo de cada personaje
(el rango de movimiento aumenta con as táctico).
- No pasar del límite del tablero.
- El personaje no puede caer en sherwood
- Salida: Celda seleccionada según porcentaje de probabilidad.
Cada personaje tendrá una directa interacción con el campo de batalla al ejecutar sus
respectivos movimientos, dado esto el jugador automático tendrá reacciones a
situaciones puntuales en las que se encuentre dentro del terreno con su respectivo
personaje, especialmente en los sectores en los cuales haya una restricción de
movimiento.
Con esto tenemos una solución mediante búsqueda de espacios de solución:
Forma de solución: -Si la restricción de movimiento es a causa de un área
restringida la forma será:
Vector {ai+bj} perpendicular al vector {mi+nj} inicial.
-Si la restricción de movimiento es a causa de una
unidad: Vector sobrante {ai+bj} en la misma dirección
del vector {mi+nj} inicial luego de saltar la unidad.
28
Restricciones:
-El vector en ambos casos se llevara a cabo si o solo si,
el personaje posee movimientos disponibles luego de la
restricción de movimiento.
-Si la última casilla de movimiento está una casilla
antes de la restricción, se llevara a cabo la solución 1 o
la solución 2 con el nuevo vector el próximo turno.
Solución: Espectro de movimientos posibles.
3.2.4 Juego general (CPU y Jugador)
Esta sección se enfoca a acciones que una vez iniciadas el desempeño no depende de
quien lo realice (entidades CPU o Jugador).
3.2.4.1 Recuperación
Instancia de recuperación de los puntos de vida de unidades. Esto suele ocurrir en
instancias llamadas por la unidad Pame o por el As Táctico el cual es mencionado en
una sección posterior.
Para aplicar el efecto de curación a cada unidad se realizara División y Conquista
realizando el mismo proceso en cada zona que deba ser afectada.
Implementando un algoritmo básico en el cual se sumen puntos de vida respectivos a
la unidad hasta alcanzar el máximo dependiendo del tipo de unidad.
3.2.4.2 Daño por Golpe o Habilidad
Se aplica similitud débil con respecto a Recuperación, diferenciándose en que se
realizara una resta de puntos de vida a las unidades afectadas.
29
3.2.4.3 Combate
Combate: Instante en que una unidad Aflige Daño a otra desgastando los puntos de
vida de aquella, la unidad afectada es capaz de contra-atacar.
Debido a que el combate se desarrolla por fases, de ataque y contra-ataque, las cuales
se reiteran según la cantidad de ataques que puede realizar la unidad según el rango.
Se utilizará Recursión para resolver este problema. Cabe mencionar que se debe
considerar en cada daño la defensa del terreno en donde se encuentren las unidades
involucradas.
Se empleara recursión manteniendo la cuenta de la cantidad de iteraciones realizadas,
la unidad dejara de atacar una vez alcanzado la repetición máxima del tipo de unidad.
La unidad contraatacante, si su rango lo permite (comprobado por algoritmo directo),
realizará una cantidad determinada de Golpes dependiendo de sus características,
esto después de recibir el daño.
En el caso de que alguna de las unidades acaben sus Golpes pero a la otra unidad le
resten, esta última seguirá hasta que ambos le queden 0 Golpes restantes. Si alguna
unidad cae en el combate (HP=0), por supuesto la acción se detiene en ese momento.
Para cada golpe se considerara la siguiente formula de asertividad del golpe:
(100−%defensadel terreno)
El rango de ataque del contraatacante será el mismo valor que su atacante o mayor si
no posee tal rango.
3.2.4.4 As Táctico
Cada 10 turnos el Jugador o CPU tiene la posibilidad, caso CPU uso será inmediato
al estar disponible, de usar una habilidad llamada As Táctico, una vez usada puede
volver a usarla luego de 10 turnos más, y así sucesivamente.
30
Existen 4 opciones a la hora de usar esta habilidad, estas son:
Tabla 5: Opciones de As Táctico
Escoger 4 casillas adyacentes entre sí (2x2), las unidades aliadas en esa zona
recuperan el total de sus HP. En caso de encontrarse el Profesor de la zona, éste
regenera el 25% de sus HP.
Escoger una columna de 4 casillas en forma vertical (4x1). Las unidades enemigas
en la zona quedan con 1 HP. El profesor no se ve afectado por esta habilidad.
Escoger 1 casilla. La unidad aliada en la casilla sube 2 niveles.
Escoger una unidad aliada y esta Aumentará su HP y la cantidad de movimientos.
Esto durante los dos próximos turnos. (Turno actual + 2 turnos)
3.2.4.5 Finalización del turno
Existen dos alternativas para acabar el turno:
Que ya no queden más movimientos en los personajes del jugador. Para este
caso, automáticamente el turno se cederá al otro jugador. Realizando el
previo aviso de ello.
Sin haber utilizado todos los movimientos de los personajes, decidir finalizar
el turno.
Esto se realiza a través de algoritmo directo en el cual se consulte por cada
movimiento realizado si quedan disponibles y facilitar un botón para el segundo
punto. En el caso de CPU este utilizara todos los movimientos.
3.2.5 Enfrentamientos
En este apartado se describe la solución a los 3 tipos de enfrentamientos que se
realizaran en la aplicación.
1. Jugador vs CPU
2. Jugador vs Jugador
3. CPU vs CPU (Simulación)
31
3.2.5.1 Jugador vs CPU
Se aplicará división en sub-problemas instanciando problemas como Generar
Tablero, Juego Jugador, Juego CPU, Juego General, Personajes, Recuperación,
Daño por Golpe o habilidad, Combate, As Táctico, Finalización de turno.
Todas estas resueltas ya anteriormente.
3.2.5.2 Jugador vs Jugador
Similitud débil con respecto al punto anterior, diferenciándose en la instanciación de
dos Juego Jugador y no Juego CPU.
3.2.5.3 CPU vs CPU
Al igual que el anterior, similitud débil con respecto al punto 3.2.5.1, instanciando
juego CPU dos veces.
3.3 DESARROLLO TORNEO
En este apartado se explica todas las soluciones a las problemáticas surgidas en el
desarrollo de un torneo de 8 jugadores con eliminación directa.
3.3.1 Torneo entre computadoras:
Se muestra a continuación la solución de esta problemática, que depende del sistema
y del usuario, ya que el emparejamiento puede ser realizado por el jugador
propiamente tal o por el sistema. De ser la segunda opción la escogida, el método de
resolución de problemas en ese caso sería “Búsqueda en espacio de soluciones”, ya
que se deben buscar todas las opciones posibles de emparejamientos entre
profesores, eliminando aquellas en las que un profesor se enfrenta a sí mismo,
aquellas en las que un profesor se enfrenta a dos o más profesores simultáneamente y
aquellas en las que un profesor se enfrente a otro profesor que ya fue eliminado o que
se encuentra en otra llave. De esa forma se obtiene un conjunto con las soluciones
adecuadas al problema.
32
Una vez realizados los cuatro pares de enfrentamientos entre profesores, queda
encontrar la forma de cómo obtener un ganador del torneo, el cual será denominado
“Profesor favorito de los niños”. Para esta nueva problemática surgida, se utiliza el
método de resolución de problemas denominado “Búsqueda en espacio de estados”,
en donde:
3.3.1.1 Representación de un estado inicial
La representación del estado inicial va a estar dada por una matriz de 4x3 en donde la
primera columna indicará el nombre del Profesor 1 y la segunda el nombre del
Profesor 2, mientras que la tercera habrá un 0 que indica que no se conoce el nombre
del profesor ganador del enfrentamiento.
(Profesor 1 Profesor 2 0Profesor 3 Profesor 4 0Profesor 5 Profesor 6 0Profesor 7 Profesor 8 0
)Figura 6: Representación de un Estado y Estado Inicial de Torneo
3.3.1.2 Representación de un estado final
La representación de un estado final viene dada por tres matrices de 4x3, 2x3, 1x3
respectivamente, en donde pueden haber todas las combinaciones posibles de
enfrentamientos. En la última columna de la última matriz saldrá el nombre del
“Profesor favorito de los niños”, ganador del torneo.
(Profesor 1 Profesor 2 XProfesor 3 Profesor 4 XProfesor 5 Profesor 6 XProfesor 7 Profesor 8 X
) (X X XX X X ) ( X X X )
Figura 7: Representación estado Final de Torneo
3.3.1.3 Transiciones
De la primera matriz se ocupara la tercera columna que corresponde al profesor
ganador de cada llave de la primera ronda y se emparejara con el profesor de la fila
33
de abajo en la misma columna resultando así una nueva matriz de 2x3, en donde
nuevamente se volverá aplica el proceso anterior, resultando una nueva y última
matriz en donde el profesor que quede en la última columna de esta matriz será el
ganador del torneo y por consiguiente el “Profesor favorito de los niños”.
3.3.2 Torneo entre usuarios y computadoras
Se utiliza el método de resolución de problema denominado Similitud fuerte con
respecto a Torneo entre computadoras. En este caso las restricciones y
emparejamientos disponibles serán mostrados por pantalla y el usuario será quien
pueda elegir de acuerdo a las posibilidades existentes, el resto permanece igual de
acuerdo a los resultados que se vayan dando entre usuarios y computadoras.
3.4 REGISTRO
En este punto, se procede a describir cada una de las soluciones de los problemas que
surgen a partir del registro de un historial de partidas de cada jugador en específico.
Esto también conlleva a un registro de los mismo jugadores que utilizan el sistema.
A fin de evitar posibles dobles personalidades con el mismo nombre en el Sistema, es
necesario un Registro Simple de Usuario en este. Para que luego este usuario pueda
Ingresar al Sistema con su nombre de Registro.
Por lo tanto, representaremos estos datos por medio de tablas la cual:
Junto al nombre del Usuario se guardarán también la cantidad de victorias y derrotas
del Jugador en cuestión. Así también la fecha y hora de su último inicio de sesión.
Con fines de obtener datos de victoria y derrotas de la CPU, de primera instancia
existirá el jugador nombrado CPU para ello.
34
Tabla 6: Representación Registro de Usuarios
Jugador Victorias Derrotas Última Sesión
CPU <Victorias CPU> <Derrotas CPU> -
<Usuario 1> <Victorias U1> <Victorias U1> <Fecha U1>
><Usuario 2> <Victorias U2> <Victorias U2> <Fecha U2>
<Usuario n> <Victorias Un> <Victorias Un> <Fecha Un>
Para el detalle de las partidas se contará con la siguiente tabla en la cual se señala
ambos jugadores participantes, siendo jugador un usuario o CPU y el ganador.
Tabla 7: Representación Registros de Partidas
Equipo 1 Equipo 2 Ganador
<Jugador 1> < Jugador 2> < Jugador G1-2>
< Jugador 3> < Jugador 4> < Jugador G3-4>
< Jugador m> < Jugador n> < Jugador Gm-n>
3.4.1 Ingreso de Usuario
Por todo lo dicho anteriormente se ocupa método de División en Sub Problemas,
teniendo de resultado:
3.4.1.1 Registro:
El usuario directamente se registrará en el sistema ingresando la información
requerida, generando una fila nueva en la Tabla 6. Con datos de victoria y derrota en
0.
3.4.1.2 Ingreso:
El usuario ingresará la información necesaria que previamente utilizó al registrarse
para acceder a su sesión. Se actualiza directamente la columna de la Tabla 6 de
Última Sesión con fecha y hora del inicio de sesión.
35
3.4.2 Registro de partidas
Luego de cada partida se deben actualizar las Tabla 6 y Tabla 7 con los respectivos
resultados. Para ello se aplica División en Sub Problemas:
3.4.2.1 Actualización Tabla 7(registro jugador vencedor de partida):
Al terminar la partida se registra ambos jugadores participantes, y además se registra
el ganador, todo esto en la misma fila.
3.4.2.2 Actualización Tabla 6(registro de jugadores, derrotas, victorias, última
sesión):
Se aplica Similitud Débil, con respecto a Actualización Tabla 7, se actualizará Tabla
6 sumando una Victoria al Ganador y una derrota al Perdedor.
3.4.2.3 Acciones en Batalla:
Se creará un archivo .txt por cada batalla nueva, en el cual se detalla cada acción de
los jugadores o CPU en la batalla. El archivo se nombrará con el número de partida
según Tabla 7 y el nombre de los participantes de la batalla.
3.4.3 Registro actividades de cada usuario en la aplicación
Cada vez que el usuario vaya realizando acciones en la aplicación, éstas se irán
registrando en un bloc de notas o archivo de extensión .txt de tal forma de tener un
completo registro de cada acción que ejercen los distintos usuarios en cada una de
sus sesiones. Así, para cada usuario, su respectivo archivo se sobrescribirá cada vez
que inicie una nueva sesión.
36
CAPÍTULO 4. DISEÑO DE LA APLICACIÓN
En el presente capítulo se explica cómo estarán estructuradas las distintas partes de la
aplicación que darán solución al problema, de acuerdo a los diagramas de clases y los
diagramas de secuencia, para así dar a conocer de forma más esquematizada y
detallada cada aspecto de la aplicación. Asimismo, mediante lo descrito
anteriormente, se pretende lograr un mayor nivel de entendimiento del cliente
respecto al diseño de la aplicación. Cabe destacar que el tipo de arquitectura que se
está utilizando en esta aplicación corresponde al MVC (modelo-vista-controlador).
En específico, se abarca:
1. Diagrama de clases
2. Mover Unidad
3. Asignar Naturaleza
4. Pausar y reanudar partida
5. Batalla entre dos jugadores
6. Pago de Mantención
7. Registro Partida
8. Reclutamiento
9. Creación y ejecución de torneo
10. Ataque
11. Diagrama aplicación general
37
4.1 DIAGRAMA DE CLASES
Figura 8: Diagrama de clases
38
4.1.1 Unidad
Cada tipo de unidad hereda cada atributo y método de la clase abstracta unidad,
específicamente la unidad Pame sobrescribe el método usarHabilidad(), la cual
curará a las unidades aliadas cercanas.
Naturaleza se ha incluido como atributo de unidad, esta se asigna directamente desde
la base de datos. Es por esta razón que se decide eliminar la clase Naturaleza.
4.1.2 Equipo
Se ha decidido que la clase con nombre desconocido será llamada Equipo, ya que
cuenta con relación con Unidad y Jugador.
Siendo:
- Una Unidad es reclutada en un Equipo / Un Equipo posee una o muchas
Unidades
- Un Equipo pertenece a un Jugador / Un Jugador tiene un Equipo
Se le ha asignado como atributo la cantidad de oro que posee el Equipo y sus
métodos relacionados con el reclutamiento de unidades y mantención de ellas. Así
como también el uso de As Táctico.
4.1.3 Batalla
Batalla se ha relacionado con Torneo con una relación de composición, ya que si se
eliminan las batallas relacionadas no será posible realizar el torneo.
Siendo:
- Una Batalla define cero o muchos torneos / Un Torneo tiene 3 o más batallas
- Una Batalla es realizada en un Mapa / En un mapa se realiza una Batalla
39
En la Batalla hay dos participantes, pueden ser CPU o Jugador dependiendo de la
selección del Usuario, luego se tiene que uno de ellos es ganador y el otro el
perdedor.
4.1.4 Casilla
Esta clase se le ha quitado el tipo abstracto ya que se consideró un objeto el cual se
podrá instanciar durante el juego. A este se le ha dado relación con Terreno (nueva
clase) que es tipo abstracto, los tipos de Terreno heredan atributos y métodos de esta
nueva clase Terreno.
4.2 DS MOVER UNIDAD
A continuación se explica y da a conocer la interpretación de lo relacionado al
diagrama de secuencias a seguir para que el jugador mueva una unidad.
40
Figura 9: DS Mover Unidad
En primer lugar, el usuario, que en todo momento está interactuando con las vistas de
la aplicación, selecciona una unidad perteneciente a su equipo. En este instante es
cuando las vistas se comunican con el controlador del tablero, quien a su vez les
retorna una respuesta a la operación de seleccionar unidad.
Posteriormente, el controlador del tablero se comunica con la matriz Mapa con el fin
de seleccionar una submatriz del mismo que tenga como centro a la unidad
seleccionada previamente. Una vez calculada esta submatriz, la matriz mapa enviará
esta información de vuelta al controlador tablero.
41
Luego, para cada casilla del tablero, el controlador del tablero deberá calcular cuales
son las casillas alcanzables que se encuentran en la submatriz obtenida en el
procedimiento anterior. Cabe destacar que lo ideal será calcular el camino más corto
desde la unidad hasta la casilla alcanzable, considerando enemigos en el camino,
árboles y el terreno Sherwood.
Una vez calculada la casilla alcanzable se informa a la casilla en la que está la unidad
seleccionada que la casilla alcanzable es, en definitiva, alcanzable.
Después de realizado todo el proceso anterior, el controlador dibuja las casillas en las
vistas del tablero y el usuario ve en su mapa cuadriculado las casillas alcanzables
para mover su unidad.
Finalmente el usuario escoge y selecciona una de las casillas alcanzables, la cual
denominaremos casilla destino. Siempre y cuando la casilla sea alcanzable, el tablero
enviará el mensaje necesario al mapa para que éste realice efectivamente el
movimiento deseado por el usuario. Una vez hecho esto el usuario verá por pantalla
como su unidad se mueve a la casilla que el seleccionó.
42
4.3 DS ASIGNAR NATURALEZA
Ahora, se explica lo relacionado al diagrama de secuencias a seguir para la
asignación de naturalezas de una unidad recién reclutada.
Figura 10: DS Asignar Naturaleza
43
Primero que todo, el usuario (siempre interactuando con las vistas) le envía el
mensaje a las vistas para seleccionar la unidad reclutada recientemente. Las vistas a
su vez se comunican con controlador Unidad para poder llevar a cabo esta solicitud
hecha por el usuario.
Una vez seleccionada la unidad recién reclutada, la vista (ventana) se comunicará
con el controlador de unidad para poder asignar aleatoriamente la naturaleza a la
unidad. El controlador a su vez para realizar dicha acción se comunica con la base de
datos y extrae desde ahí una naturaleza (cualquiera).
Después de realizado el paso anterior, se le asigna concretamente a la unidad
reclutada la naturaleza obtenida anteriormente de forma aleatoria y se muestra al
usuario, a través de las vistas, cuál fue la naturaleza asignada.
Finalizado el paso anterior, a través de las vistas se solicita al usuario seleccionar una
naturaleza disponible para la misma unidad. El usuario realiza la acción necesaria
para seleccionar naturaleza comunicándoselo a las vistas, quienes luego se lo
comunicaran a controlador unidad y éste a su vez se comunicará con la base de datos
en donde se encontrarán las naturalezas disponibles (exclúyase la naturaleza asignada
aleatoriamente). Luego de obtenida la información de la base de datos, el
controlador Unidad se las comunica a las vistas para que el usuario escoja una.
Una vez escogida dicha naturaleza, las vistas se lo comunican al controlador Unidad
y este se las asigna efectivamente a la unidad seleccionada. Finalmente, se muestra
por pantalla las dos naturalezas correspondientes a la Unidad.
44
4.4 DS PAUSAR Y REANUDAR PARTIDA
Figura 11: DS Pausar y Reanudar Partida
El usuario, interactuando con la ventana menú, envía el mensaje para pausar al juego.
Dicho mensaje es transmitido desde las vistas hacia el controlador ventana, quien a
su vez se comunica con el controlador del juego, quién realmente pausa el juego.
Una vez pausado el juego se envía un mensaje por pantalla al usuario diciendo que el
juego se ha pausado y siempre con la opción para reanudar la partida.
Una vez que el usuario decida reanudar la partida, se comunicará con las vistas
quienes lo harán con el controlador de ventana y éste con el controlador de juego,
45
quien, en definitiva, reanuda la partida. Una vez hecho el procedimiento anterior
desaparece de las vistas el menú y se continúa con la partida.
4.5 DS BATALLA ENTRE DOS JUGADORES
A continuación se detalla y explica el diagrama de secuencia a seguir en una Batalla
entre 2 Jugadores.
Figura 12: DS Batalla entre dos jugadores
4.5.1 Inicio
El usuario interactuando con las vistas envía un mensaje de que está listo para jugar,
ya que esta batalla se realiza entre dos jugadores, el jugador 2 debe realizar la misma
acción.
Una vez que el jugador 2 notifique su alistamiento, la vista notificará a su
controlador que se inicie la batalla, el cual se encargará de crear una nueva vista para
46
la batalla y dar aviso al controlador de juego que se ha iniciado una partida. El
controlador de juego solicitará crear un registro nuevo para esta partida.
4.5.2 En juego
La nueva vista tiene disponible la recepción de acción de parte del usuario en turno,
luego que el usuario realice una acción sobre la vista, esta notificará a su controlador
sobre ello y este notificará al controlador de juego sobre la acción a realizar.
Luego el controlador de juego solicitara registrar la acción al controlador de registro
(referencia registroPartida), sin esperar respuesta, mientras realiza la acción. Para
entonces solicitar al controlador de vista que muestre la acción en la vista
correspondiente.
Esta vista mostrará la acción y solicitará nuevamente al usuario alguna acción. Esto
se repetirá mientras la acción del usuario no sea Finalizar el turno.
Una vez que finalice el turno el jugador 1, la secuencia se repetirá nuevamente pero
en este caso para jugador 2, y así sucesivamente.
4.5.3 Fin del juego
En el transcurso del juego, si un profesor de uno de los equipos muere, controlador
juego solicitará registrar el ganador y enviará un mensaje a sí mismo para dar
termino a la batalla.
47
4.6 DS PAGO MANTENCIÓN
A continuación se detalla el diagrama de secuencia pagoMantención()
Figura 13: DS Pago Mantención
Debido a que esta secuencia nace a pedido de una instancia por el controlador de
juego, esta no presenta actores.
De primera, el controlador de juego solicita pagar la mantención de unidades del
equipo de turno. Delegando la operación al controlador de Equipo.
El controlador de Equipo solicitara la información necesaria del Equipo de turno, y
solicitara el costo total a controlador de Unidad. Controlador de Unidad consultara el
costo de cada unidad del equipo respondiendo la suma de ellas al controlador de
equipo.
48
El controlador de equipo cobrará al equipo de turno el costo total obtenido
descontando de su oro. Confirmando la acción.
Para luego el controlador de equipo confirme a controlador de juego que la operación
se ha realizado.
4.7 DS REGISTRO PARTIDA
Figura 14: DS Registro Partida
49
Al igual que el punto anterior, esta secuencia de órdenes nace de una solicitud de
controlador de juego. El cual solicita crear un registro de primera instancia, esto
mantiene al controlador de registro en espera de solicitudes hasta que el juego
termine.
En el momento que controlador de juego solicita crear registro, controlador de
registro creará un nuevo documento devolviendo respuesta de archivo creado
correctamente.
Luego controlador de registro esperará acciones de parte de controlador de juego
para registrarlas en el documento anteriormente creado. Respondiendo con escritura
exitosa. Esto se realiza mientras un equipo aun no haya ganado.
Luego, una vez que controlador de juego desee registrar un ganador, controlador de
registro escribirá en el documento la muerte del profesor correspondiente, para luego
cerrar el documento.
Luego de esto controlador de registro actualizará las tablas de la base de datos con el
correspondiente ganador y perdedor, y sumando victorias y derrotas del jugador o
cpu.
Entonces controlador de registro retornará a sí mismo juego terminado.
50
4.8 DS RECLUTAMIENTO
Figura 15: DS Reclutamiento
En primera instancia el usuario se comunicara directamente con la ventana
laboratorio, la cual tendrá la lista de personajes a reclutar, a través de esta venta el
usuario seleccionara el correspondiente personaje a ser reclutado. Al momento de
elegir este personaje, se enviara la información al Controlador de reclutamiento el
cual es el encargado de los cambios que se generen de oro total y además la
invocación de un personaje al campo de batalla.
Luego de realizar el cambio debe existir el otro paso, para completar la entrega total
del personaje, la cual es la asignación de naturaleza, para realizar esto, el controlador
del reclutamiento tendrá directa interacción con la asignación de Naturaleza (con sus
respectivas acciones que llevaran a la asignación correcta de estas características).
Para finalizar el proceso, control de reclutamiento tendrá el trabajo de enviar la orden
para que se agregue la nueva unidad como también la modificación de oro total. El
51
mensaje será enviado al controlador de ventana, el cual está encargado directamente
de lo que aparece por pantalla, luego de esto, el siguiente paso será enviar la orden
para que los correspondientes cambios se generen en la ventana del juego.
4.9 DS CREACION Y EJECUCION TORNEO
Figura 16: DS Creación y ejecución Torneo
Para realizar un torneo el primer paso es crear uno, para esto el usuario en primera
instancia deberá interactuar con el menú de torneo el cual le permitirá la creación del
52
torneo, con esto la opción tomada en el menú de torneo será trabajada principalmente
por el controlador de torneo, el cual generará la estructura del torneo pero también
devolverá un mensaje el cual será solicitar los participantes de dicho torneo al
controlador de ventana, para que así la solicitud de ingreso de los nombres de
participantes se muestre por pantalla.
Luego de pedir el ingreso de los participantes, el usuario deberá ingresar los
participantes directamente al menú del torneo, el cual luego de obtenido este mensaje
lo enviara al controlador del torneo el cual se encargara de generar la tabla de
participantes que luego mediante un mensaje con el objetivo de crear la matriz con
los jugadores, se enviara al objeto torneo. Luego de la creación de la matriz se
procederá a generar los procesos de vista de la preliminar, que luego de que se
generara en el objeto torneo, será enviado al controlador de ventana para generar la
visualización hacia el menú del torneo en donde este se lo proyectara al usuario.
El segundo paso para la ejecución del torneo será iniciar el torneo, que a través del
usuario (que es el encargado de iniciar el proceso) dará el inicio en el menú del
torneo, para que luego el respectivo torneo generado anteriormente se ejecute a
través del controlador del torneo.
Definir el ganador de cada batalla será un paso primordial para generar la nueva
matriz con ganadores. El controlador del torneo tendrá una clara relación con la
referencia batalla (que incluye todos los procesos para seleccionar un ganador), la
cual le indicara el ganador de la batalla.
En el mismo controlador del torneo se creara la nueva tabla con ganadores, en donde
la creación de la nueva matriz estará dada por el objeto Torneo, se generara una
actualización correspondiente a las preliminares para luego proyectar esto al usuario
por pantalla mediante el mensaje al controlador de ventana, que enviara la orden de
visualizar la nueva preliminar.
53
4.10 DS ATAQUE
Figura 17: DS Ataque
54
En primer el usuario envía el mensaje de selección de unidad con la cual quiere
atacar al tablero del juego para iniciar el proceso, este mensaje desde el tablero será
enviado hasta el controlador de la ventana la cual generará la visualización de la
unidad marcada, esto a través de un mensaje que al tablero de juego.
Luego de que la unidad sea seleccionada, claramente el usuario realizara su segunda
acción la cual es seleccionar el modo de ataque de su unidad, esto mediante un
mensaje hacia el tablero, el cual luego será enviado a aliado, que se encargara de
buscar los enemigos validos dentro del rango. El resultado de la acción anterior será
un mensaje que se dirigirá al controlador del tablero, quien será el encargado de
generar el mensaje de muestra de enemigos validos en el rango de la unidad,
enviando esto a ventana para que sea visualizado por el usuario.
Mostrado la gama de enemigos válidos, lo siguiente es la selección el enemigo a
atacar a través de la ventana, para que luego esta acción sea enviada al controlador
del tablero, el cual luego de interpretar el mensaje comenzara el proceso de muestra
del enemigo seleccionado enviando un mensaje al tablero para que muestre al
usuario el enemigo seleccionado.
El proceso que queda es realizar la orden de ataque, el cual en primera instancia será
seleccionado mediante el tablero, este enviara el mensaje de atacar al enemigo hacia
la unidad aliada, el cual con una directa interacción con la unidad enemiga se
calculara los daños y experiencia que se recibirá, esto conlleva a que se ejecuten los
procesos de modificación de vida de la unidad enemiga, como también la
modificación de experiencia de la unidad aliada y su vida. Este proceso llevara a que
se generen valores los cuales deben ser mostrados por pantalla, enviando los valores
del combate hacia el controlador del tablero, el cual enviara la orden de animación
con los respectivos valores obtenidos al tablero en donde serán proyectados al
usuario.
55
4.11 DS GENERAL
A continuación se da a conocer la interpretación del diagrama de secuencia general
enviado por el cuerpo docente.
Figura 18: DS General
56
En primera instancia se inicia la aplicación, en donde el controlador del Menú envía
un mensaje de inicio para generar una nueva ventana a menú Ventana, luego de esto
se necesita una nueva conexión a la base de datos que implique la verificación de un
usuario conocido, o la creación de un nuevo usuario. Luego de esto mediante un
mensaje de retorno a menú Ventana se indica la necesidad de consultar cuentas a la
base de datos en donde luego de obtener dichas cuentas registradas, se mostrara por
pantalla las cuentas ya almacenadas en la base de datos, que posiblemente alguna de
estas corresponda al usuario.
Para el primer caso en donde el jugador no posee una cuenta, debe elegir la opción
Nuevo Usuario que estará en el menú Ventana, aplicado el nombre que el usuario
haya elegido actuará el controlador del menú directamente con la base de datos para
agregar el nuevo usuario, con esto también la base de datos en su caso indicara si el
nombre de usuario es válido o no.
En el segundo caso, en donde el usuario ya posee un registro en la base de datos (ya
tiene cuenta), seleccionará su cuenta directamente en la ventana, luego de esto se
responderá con un mensaje de ingreso correcto, para luego continuar con el
procedimiento de inicio en la opción del menú, que será una orden de inicio del
juego en sí hacia el controlador del menú que se relacionara directamente con el
controlador previo del inicio de partida, creando así una nueva ventana de la previa
del juego, en donde esta le solicitara al usuario los parámetros que van a generar la
nueva batalla, así mismo el usuario responderá con los respectivos parámetros a la
ventana del juego para que luego sean configurados en el controlador de la previa
partida.
Posterior a esto, el controlador Previa le envía los parámetros ingresados por el
usuario al controlador de batalla, para que este a su vez, le envíe éstos al controlador
Tablero. De esta forma el controlador tablero se comunicará con las vistas para que
luego estas se comuniquen con el usuario solicitándole el tipo de tablero que desea.
57
Una vez que el usuario selecciona el tipo de tablero, se lo comunica a las vistas y a
continuación las vistas envían el mensaje al mapa para que se genere éste.
Una vez generado el mapa se generarán las vistas de batalla y en este punto se deberá
realizar el combate entre dos jugadores (Ref. Combate entre 2 jugadores). Cuando
haya finalizado el combate, el controlador batalla enviará el resultado de ésta al
controlador Menú el cual utilizando éste resultado, mostrará a través de las vistas,
una animación de victoria del jugador.
58
CAPÍTULO 5. DESCRIPCIÓN DE LA APLICACIÓN
Esta aplicación, como ya se ha dicho en reiteradas ocasiones, ha sido elaborada con
el fin de solucionar el problema en el que se encuentra el departamento de ingeniería
informática (DIINF) que consiste en dirimir quien es el profesor favorito de los
alumnos. Esto a través de batallas virtuales de tipo RPG (Véase referencia en página
1) en las cuales se enfrentan los profesores involucrados en el conflicto con sus
respectivos aliados.
Utilizando la arquitectura MVC, la cual permite diferenciar claramente cada
elemento correspondiente a ésta mediante paquetes, entre los cuales se encuentran:
5.1 VISTAS
En este paquete se encuentran las siguientes ventanas, que se utilizan para
comunicarse por pantalla con el usuario de la aplicación.
5.1.1 Vista Menú Inicial
Figura 19: Vista Menú Inicial
59
Esta ventana permitirá al usuario ingresar a la aplicación, o bien, si es que el usuario
no tiene una cuenta que lo permita, la persona podrá tener acceso a la ventana de
registro para crear una.
5.1.2 Vista Menú Registro
Figura 20: Vista Menú Registro
En esta ventana el usuario podrá crear una cuenta en caso de no tenerla y podrá
entrar finalmente a la aplicación. Como esta acción no se realiza por arte de magia el
nombre que ingrese el usuario será comprobado en la base de datos de tal forma que
no se repita.
Una vez hecho esto el usuario podrá ingresar directamente al menú principal.
60
5.1.3 Vista Menú Principal
Figura 21: Vista Menú Principal
En esta parte de la aplicación el Usuario podrá escoger entre tres opciones a realizar,
las cuales pueden ser Partida 1 vs 1, Torneo o Historial de partida.
Si escoge Partida 1 vs 1, el jugador accederá a una nueva ventana donde podrá
configurar dicha partida de la forma en que él lo desee.
Si el cliente decide seleccionar la opción Torneo, éste accederá a una nueva ventana
en donde podrá configurar las opciones del torneo a realizar.
Finalmente, si el cliente hace clic en Historial de Partidas, éste tendrá acceso a la
ventana en donde se mostrarán todas las partidas que el usuario ha jugado, mostrando
para cada partida el ganador de ésta.
61
5.1.4 Vista Configurar Partida
Figura 22: Vista Configurar Partida
En esta vista, el usuario puede configurar su partida. Existen tres opciones en
Modalidad de Juego, las cuales son: 1. Jugador vs Jugador, 2. Jugador vs CPU y 3.
CPU vs CPU.
Se añadió un toolTipText con el fin de dejar en claro el objetivo del textField Nombre
Jugador2, el cual sólo debe ser llenado en caso de que el Usuario escoja la opción 1.
Al igual que en la ventana Menú Inicial, en este caso si el Jugador2 no posee cuenta,
puede hacer clic en el botón Registro y será redirigido al Menú Registro.
Finalmente, el usuario podrá escoger uno de los mapas predeterminados por el
sistema o uno generado aleatoriamente.
62
5.1.5 Vista Tablero
Figura 23: Vista Tablero (sin restricciones de terreno)
En esta vista es donde se desarrollará la aplicación, donde el usuario interactuará la
mayor parte del tiempo con las otras partes del juego. En esta vista el usuario podrá
ver la información del terreno mediante las herramientas toolTipText, al igual que la
información de los personajes que se encuentran sobre cada terreno.
63
5.2 MODELOS
Existen tres carpetas de este tipo. Una de ellas es la carpeta Mapa (Modelo.Mapa) en
donde se encuentran las clases Casilla, Terreno, tCalle, tCasitas, tCiteCamp, tDiinf,
tForo, tKiosko, tLab, tPastos, tSherwood. Donde las 9 últimas subclases se extienden
de la clase Terreno. Además en este modelo se encuentran las clases Casilla, Mapa y
Terreno. La otra carpeta es la denominada Unidades (Modelo.Unidades) donde se
encuentran las clases Unidad, uANS, uAlumno, uAyudante, uCachorro, uCdA,
uPame, uProfesor. Donde todas las subclases se extienden de la clase padre Unidad.
Por otra parte se tiene el modelo Batalla (Modelo.Batalla) en donde se encuentran las
clases Batalla, CPU, Equipo y Jugador.
5.3 CONTROLADORES
Se tiene el controlador denominado controladorTablero, el cual actúa como
“listener” de todas las acciones que el usuario ejecute en la vista Tablero. Además, se
tiene el controlador llamado Juego, quien es el que dará el arranque para que se
muestre por pantalla el Tablero. Por otra parte se tiene el controladorUnidad
(ctUnidad) quien es el que calculara la matriz alcanzable para las distintas cantidades
de movimientos que contenga cada unidad así como también iniciará sus
movimientos y ataques en el controlador de tablero reciba las ordenes.
Se cuenta con un controlador de partida (ctPartida) el cual contiene los métodos a
utilizar por ambos equipos durante la batalla, como el cobro de mantención, inicio de
una pelea entre unidades, asignación del ganador y perdedor (identificación de la
muerte de alguna unidad “profesor”) y envía la información a respaldar en un
registro de texto como también guarda el resultado de la partida en la base de datos.
64
A continuación se establece la comparación entre el diseño y la construcción final de
la aplicación. Para realizar esta comparación es necesario tener en cuenta el diagrama
de clases y los distintos diagramas de secuencias presentados con anterioridad.
1. Diagrama de clases
Unidad: Se mantiene la misma cantidad de unidades expuestas en el diagrama.
La relación entre las unidades y su clase padre denominada “Unidad” también
se mantiene. Los atributos de la clase unidad son los mismos planteados en el
diagrama de clases. Se añadieron los atributos Experiencia, LimExperiencias,
aumentHP, aumentAttack y aumentHit, en donde LimExperiencia corresponde
a un arreglo el cual contiene los valores de experiencia que necesita la unidad
para subir de nivel por cada nivel (hecho a partir de la Tabla 3 del enunciado
del proyecto), por otra parte los tres últimos atributos agregados, corresponden
a arreglos que contienen el respectivo valor de aumento de stats de cada unidad
por nivel(están hechos a partir de la Tabla 4 del Enunciado del proyecto) .
Además mediante el constructor “super” cada subclase de la clase “Unidad”
posee sus respectivos valores respecto a los atributos de ésta última. A la clase
unidad se la añadieron los métodos getDamage, getNewHP, ApplyAttack,
ContraAtaque, getAtaque, getNivel, getMovimientos, getCant_Golpes,
getExperiencia, lvlUP, upHP, upHit, upAttack, morir.
Casilla: Tiene como atributos la unidad que está en el terreno y el respectivo
terreno que está en una casilla. Como métodos se tiene hasta el momento
setTerreno, setUnidad, getUnidad y getTerreno.
Terreno: En esta clase se tiene como atributos el mencionado en el diagrama
de clases y además se le agrego el atributo “dimensión”, el cual corresponde a
un array de enteros. Por otra parte en esta clase, se tiene el constructor de ésta
misma. Se mantiene la misma cantidad de subclases pertenecientes a la clase
padre “terreno” y por ende la misma relación entre ellas.
65
Mapa: Como atributos se encuentra el Tablero que corresponde a una matriz
de casillas (tipo de dato) y también en esta clase se tiene su respectivo
constructor.
Batalla: Como atributo se tienen ParticipanteUno, ParticipanteDos, Ganador1,
Ganador2 todos de tipo jugador. Por otro lado se tiene el respectivo constructor.
Jugador: De momento se tiene como atributos en esta clase el nombre del
jugador que corresponde a un string. Además se tiene como atributo una id de
registro que corresponde a un int. Finalmente como métodos, tenemos el
constructor de la clase y el método Jugar ().
CPU: Respecto al diagrama de clases presentado más atrás en el informe, a esta
clase se le añadió el método Jugar () y además mediante la palabra reservada
“super” se llama al constructor de la clase padre “Jugador”. De esto se puede
inferir que cambió la relación de esta clase con respecto al diagrama de clase
puesto que ahora la clase CPU heredera de la clase padre Jugador.
Equipo: Se tiene como atributo el Oro del equipo, que es de tipo int. Además,
en comparación con el diagrama de clases, se añadió el atributo que es un
ArrayList de tipo Unidad que corresponde a las unidades que posee cierto
equipo. Como métodos se encuentran los mismos presentados en el diagrama.
2. Diagramas de Secuencias
Mover Unidad: El jugador selecciona la unidad correspondiente a su bando
mediante el clic izquierdo del mouse. Ésta acción pasa desde la vistaTablero a
lo que es el controladorTablero (ct), en donde se realizan efectivamente las
acciones. Cabe destacar que si el usuario deja el puntero del mouse sobre la
unidad cierto tiempo, ésta mostrará un toolTipText que indicará información de
esta misma. Dependiendo de la cantidad de movimientos disponibles de la
unidad se procederá a calcular la matriz alcanzable para cada unidad media el
controladorUnidad (ctUnidad), arrojando una matriz con true y false según
corresponda a cada casilla. De esta forma el usuario podrá seleccionar la casilla
66
destino mediante el clic derecho del mouse. Dicha acción al igual que la
primera acción, pasará desde la vistaTablero a lo que es controladorTablero
(ct), quien en definitiva hará efectivo el movimiento de la unidad a la casilla
destino.
Pausar y Reanudar partida: Esta opción no se ha realizado hasta el momento
ya que se han priorizado otras funcionalidades.
Asignar Naturaleza: Esta opción no se ha realizado hasta el momento ya que
se han priorizado otras funcionalidades.
Batalla entre dos jugadores: Esta funcionalidad se aborda a partir de otras
funcionalidades tales como movimiento, ataque, muerte, reclutamiento de
unidades. Como también los cambios de turnos de los jugadores. El acceso a
esta funcionalidad se realiza a través del menú principal del juego instanciando
diversos controladores y vistas para su funcionamiento.
Pago Mantención: Se realiza al inicio de cada turno de un jugador
ejecutándose desde el controlador de partida de forma automática. Realizando
el cobro de mantención de cada unidad que se posea en ese instante del juego
se indica al jugador el costo total de sus unidades y se actualizará el oro que
posee el equipo.
Registro Partida: Esta funcionalidad se ejecuta con cada acción que el jugador
realice o que ejecute el propio sistema de forma automatizada. Esta es
ejecutada por el controlador de partida
Reclutamiento: Funcionalidad convocada desde el controlador de equipos. El
jugador es capaz, mediante un botón situado en la parte inferior de la vista
tablero, iniciar una nueva vista para elegir las unidades permitidas a reclutar. El
jugador selecciona una unidad y se reclutara en el laboratorio del equipo
realizando el cobro pertinente de la unidad, descontándose el oro del equipo
correspondiente.
Creación y Ejecución Torneo: Esta funcionalidad aún no se realiza puesto
que la CPU y BD aún no están desarrolladas en su totalidad.
67
Ataque: Funcionalidad que es iniciada por el controlador partida utilizando el
controlador de unidades para rectificar ataques y sus contrataques, esto
comprobando rangos y daños de cada unidad, así como también la defensa de
los terrenos que se encuentren estas.
General: Engloba todas las acciones desde que se inicia el juego hasta el
término de una partida. Es iniciado por el controlador Juego el cual contiene el
método main de la aplicación. Luego este instancia diversos controladores
como los de vistas (tablero, menú, reclutamiento, etc) y partida, los cuales
también instancian a otros para el correcto desarrollo del juego siguiendo las
jerarquías respectivas.
5.4 BASE DE DATOS
Se emplea MySQL utilizando el conector de comunicaciones JDBC incorporado en
Netbeans. Se realizan tablas de datos para guardar el registro de cada jugador junto
con sus victorias y derrotas. Esta tabla se utiliza principalmente en el Log In a la
aplicación y cuando el jugador desee consultar sus victorias y derrotas en el juego.
Se tiene una tabla de datos con todas las partidas jugadas en el juego, con
información de los participantes de la partida y su ganador.
Se cuentan con tablas de terrenos como de también de unidades, las cuales guardan la
información de cada atributo inicial de estas entidades. Permitiendo su fácil
modificación para un reajuste de sus atributos, equilibrando la experiencia en juego.
68
CAPÍTULO 6. CONCLUSIONES
En esta etapa final del proyecto se ha puesto especial énfasis en lo que se refiere a la
jugabilidad y vistas de la aplicación. Específicamente lo que es el movimiento de las
unidades, sus ataques, sus experiencias y niveles, sus niveles de defensa dependiendo
del terreno, etcétera. Así como también se hizo en las partes gráficas, por ejemplo: no
se quiso representar las unidades de manera abstracta (colores, símbolos, etc.), sino
que se representaron de la manera más “fiel” posible a lo que se ve en este tipo de
juegos. Lo mismo pasa con los distintos terrenos que se tenían, en ese caso se
intentaron hacer lo más parecido a la realidad.
Uno de los problemas más importantes que posee la aplicación trata del movimiento
de la unidad, actualmente la unidad pasa por alto cualquier tipo de restricción en los
terrenos que le impida estar ahí, como por ejemplo Sherwood. Además, la unidad se
“tele transporta” a la casilla destino, y no avanza casilla por casilla, esto debido a que
el algoritmo que se requiere para realizar este tipo de movimiento (algoritmo de
Dijkstra) es muy complicado de realizar.
A medida que se fue avanzando en la implementación del código, se da cuenta de
ciertos errores o incongruencias que se encontraban en los diagramas expuestos en
un principio. Es por esto que ciertos atributos y métodos fueron creados, modificados
o eliminados.
De esta forma, se puede decir que se logró una aplicación “jugable” para dos
jugadores reales.
En lo que respecta a los métodos de resolución de problemas aplicados en el
desarrollo a lo largo de todo el proyecto, se puede concluir que el método de
subdivisión de problemas aplicado al proyecto -en general-, en parte sirve mucho
para separar los problemas (como su nombre lo indica), pero por otra parte hay que
tener mucho cuidado porque al dividir tanto el problema principal, en vez de
simplificar la solución de éste, ésta se puede tornar mucho más difícil y engorrosa.
69
Uno de los problemas que surgió al momento de intentar unificar la aplicación en su
totalidad fue que se tenían muchos fragmentos de esta y fue principalmente por este
motivo que se hizo complicada esta etapa.
70
CAPÍTULO 7. BIBLIOGRAFÍA
Enunciado Proyecto Métodos de Programación 01-2015
Clase 03 Métodos de Programación 01-2015
Sitio web ElOtroLado.net (Definición de RPG) [online]
Disponible en: http://www.elotrolado.net/wiki/Juegos_RPG_en_PC
Clase 05 , 06 , 12 Métodos de Programación 01-2015
Clase 19 y 20 Métodos de Programación 01-2015
71
AXEXO A: TIEMPOS UTILIZADOS.
Tabla 8: Actividades y tiempos utilizado HITO 1
ActividadEstado
Inicial
Encargad
oDía
Hora
Inicio
Hora
Fin
Estado
Final
Lectura de
enunciado
Lectura
superficialTodos 05/04
20:00hr
s
21:00hr
s
Lectura
profunda del
enunciado
Análisis del
problema
Comprensió
n parcial del
problema
Todos 07/0414:20hr
s
15:25hr
s
Comprensió
n del
problema en
su totalidad
Solución
del
problema
Ideas
básicas de
solución
Todos 08/0415:30hr
s
18.30hr
s
Ideas
elaboradas
con sus
respectivas
soluciones
Elaboració
n Informe
Ideas en el
aireTodos 08/04
15:30hr
s
23:45hr
s
Ideas
traspasadas
al informe,
ya
estructurado
Finiquito
Informe
Informe
avanzadoTodos 14/04
16:30hr
s
23:00hr
s
Informe
terminado
72
Tabla 9: Actividades y tiempos utilizados HITO 2
ActividadEstado
Inicial
Encargad
oDía
Hora
Inicio
Hora
Fin
Estado
Final
Lectura
diagramas
Diagramas
no leídosTodos
29/04 -
30/04
14:00hr
s
15:00hr
s
Lectura
profunda de
cada uno de
los
diagramas
Análisis de
los
diagramas
Comprensió
n parcial de
los
diagramas
Todos30/04 -
02/05
14:00hr
s
15:20hr
s
Comprensió
n de los
diagramas
en gran
medida
Realizar
Completar
Corregir
Modificar
diagramas
Ideas
básicas para
realizarlo
Todos02/05 -
10/05
14:00hr
s
19:00hr
s
Diagramas
hechos en su
totalidad
Añadir
capítulo de
diseño al
informe
Ideas en
papelTodos
11/05 -
12/05
15:30hr
s
23:45hr
s
Capítulo de
diseño
escrito en el
informe
Revisión
informe
final
Informe
avanzadoTodos 13/05
13:50hr
s
23:30hr
s
Informe
actualizado a
la fecha
13/05
73
Tabla 10: Actividades y tiempos utilizados HITO 4
ActividadEstado
InicialEncargado Día
Hora
Inicio
Hora
FinEstado Final
Leer Enunciado
Lectura
Profunda
del
enunciado
Todos27/07 –
11/09
15:00
hrs
17:00
hrs
Lectura
localizada de
ciertas partes
del
enunciado.
Planteamiento
problema de la
etapa
Problema
no
identificado
Todos 27/0716:00
hrs
16:30
hrs
Problema
completamen
te
identificado.
Objetivos de la
etapa
Problemas
localizados.Todos 10/08
13:00
hrs
13:50
hrs
Objetivos
claros de la
etapa.
Desarrollo
problemas y
objetivos
Algunas
nociones
respecto a
problemas
Todos14/08 –
Hoy
16:00
hrs
19:00
hrs
Ciertos
objetivos
logrados.
Documentación
Conocimie
ntos
básicos.
Todos14/08 -
Hoy
00:00
hrs
03:30
hrs
Información
más acotada.
Escritura y
Formato
informe
Informe
hecho hasta
Hito 2
Todos31/09 –
11/09
12:00
hrs
16:00
hrs
Informe
completo de
acuerdo al
avance del
proyecto.
74
![Mecánica clásica [usach]](https://static.fdocuments.co/doc/165x107/557e5d49d8b42a506d8b4687/mecanica-clasica-usach.jpg)
