Proyecto DAM Fin Ciclo

 

 

PROYECTO FIN DE CICLO DAM

Imp mple leme ment nta aci ción ón de un vi vi-deoj de ojue ueg g o en J AV AVA A 

Entr ega Fin Fina al de Pro Proyecto yecto Fase: 3: Entre

 

 

Índice 1.   1.

Identificación Identificación de necesidades y diseño del proyecto ............................................ ................................................................ ................................. ............. 3  3 

1.1

Contextualización y Justificación ..................................................... ............................................................................................................ ......................................................... 3

1.2

Estudio inicial y planificación del proyecto.................................................................. proyecto.............................................................................................. ............................ 5

1.3

Aspectos fiscales y laborales............................................................................... laborales.................................................................................................................. ................................... 10

1.4

Viabilidad económica económica ............................................. ................................................................................................... ................................................................................ .......................... 11

1.5

Modelo de solución ..................................................................................................... ............................................................................................................................... .......................... 13

2.   2.

Ejecución del proyecto y pruebas ...................................................... ........................................................................... ......................................... ............................ ........ 16  16  

2.1

Riesgos de ejecución del proyecto .................................................. ........................................................................................................ ...................................................... 16

2.2

Documentación Documentación de ejecución ....................................................................................................... ................................................................................................................ ......... 17

2.3

Incidencias ................................................... .......................................................................................................... .......................................................................................... ................................... 51

2.4

Pruebas y soporte ................................................. ........................................................................................................ ................................................................................. .......................... 52

 

 

Impl mple ementación de d e un videoju v ideojue ego en JAVA (DAM) 1. Ide Ident ntifi ificación cación de nece n ecesid sidade adess y dis dise eño del proyecto 1.1 1. 1 Conte Contextualiza xtualización ción y Justi Justificación ficación ▪ 

Descripción del proyecto.

El proyecto consiste en realizar un videojuego clásico como una aplicación de escritorio, en el que los participantes puedan inscribirse online y competir por conseguir la mejor puntuación posible. Esta puntuación aparecerá en un listado constantemente actualizado. En este caso se implementará el videojuego de Pac-Man. Los participantes podrán elegir el nivel de dificultad del juego. El nivel de dificultad se distinguirá por la cantidad de fantasmas en el juego, duración de los bonus, velocidad e inteligencia de los fantasmas. Se construirán diferentes pantallas que irán cambiando conforme avance el juego.

▪ 

Tipo de empresa/organización que implementará el proyecto.

La empresa que implementará el proyecto se establece según su tamaño como una microempresa , puesto que dispone de 8 trabajadores y su cifra de negocios es ≤ 2 millones de €.  La empresa está ubicada según el sector económico dentro del sector terciario , puesto que es prestadora de servicios. Esta empresa tiene personalidad jurídica puesto que está constituida por un conjunto de personas que constituyen una sociedad, en este caso el tipo de empresa es una Sociedad Colectiva puesto que los diferentes propietarios aportan capital y trabajo en común, con las siglas “ S.R.C.” añadido al nombre.

[NOMBRE DEL ALUMNO] [CICLO]  

PÁGINA 3

 

  El organigrama de la empresa es el siguiente:

Gerencia Gerente

Jefe Departamento

Contable

Prog. Senior

Programador DAM

Programador DAM

GS. DAM

Martín MZR

▪ 

L. Contabilidad Contabilidad

Programador DAW GS. DAW

Programador ASIR

Administrtivo

GS. ASIR

GS Gestion

Necesidades de demandada que cubre el proyecto asociadas con las necesidades del cliente.

Necesidades del cliente

Necesidades cubiertas

Realizar un videojuego clásico como una aplicación de escritorio.

Implementar código para realizar el  juego Pac-Man Pac-Man en JAVA. Editar un manual de instrucciones.

Elegir el nivel de dificultad del juego

Implementar código para inteligencia adaptativa de los fantasmas, cantidad de los mismos y velocidad.

Inscripción online del jugador y registro de puntuaciones.

Descargar el juego desde la web.

[NOMBRE DEL ALUMNO] [CICLO]  

Realizar página web. Implementar una base de datos con los nombres de los jugadores, sus puntuaciones, fechas de registro y máximas puntuaciones. Habilitar enlace en la web que contenga el ejecutable del juego, previo registro.

PÁGINA 4

 

 

1.2 1. 2 Estudio inic inicial ial y planificación del del proyecto ▪ 

Fases del proyecto y su contenido.

Las fases del proyecto las podemos dividir en: 1.

 Análi  An álisi si s:  Analizamos las necesidades de los usuarios del futuro sistema que deben ser satisfechas, en este caso, al ser un programa de entretenimiento, simplemente bastará con que el usuario tenga acceso al juego y disfrute de su contenido. En cuanto a las necesidades del cliente que realiza el encargo, como ya hemos dicho, será el realizar el juego, y llevar un registro de los usuarios, así como de su puntuación y tiempo de juego.

2.

Diseño: Elaboramos un esquema donde se van a contemplar los elementos necesarios para que el sistema funcione según lo especificado en el análisis, así como la organización del sistema para su construcción para poder optimizar los recursos en la producción del mismo. Como resultado obtendremos un documento de carácter gráfico donde se representan todos los componentes del sistema y la organización de cada uno de ellos. En definitiva, elaboraremos los planos de lo que se va a construir.

3.

Codificación:  En esta fase se implementará lo que hace funcionar el sistema software. Se construirá, por separado, cada uno de los elementos que se han definido en la fase de diseño utilizando para ello las herramientas adecuadas para ello, como lenguajes de programación, sistemas de información, bases de datos, etc. En esta fase también se construirán todos los elementos para realizar las pruebas de software necesarias.

4.

Integración:  Una vez construidos todos los elementos se procede a unirlos con el objetivo de implementar el sistema completo. Es en esta fase donde se realizan las pruebas de forma exhaustiva para comprobar que el sistema completo funciona según lo esperado.

5.

Mantenimiento:  Durante la fase de explotación del software siempre es necesario realizar cambios y ajustes, bien para corregir errores no detectados durante la fase de desarrollo, para introducir mejoras o implementar nuevas funcionalidades. Si se detecta cualquiera de estas situaciones el sistema ha de evolucionar para responder a las nuevas demandas y todo ello se desarrolla en esta fase.

[NOMBRE DEL ALUMNO] [CICLO]  

PÁGINA 5

 

  ▪ 

Objetivos del proyecto.

➔ 

Implementar un videojuego de escritorio escritorio (PAC-MAN). (PAC-MAN). o  Implementar el menú principal. o  Implementar la pantalla de juego. o  Implementar el contenido del nivel. o  Implementar los personajes. o  Implementar la función de pausa. o  Implementar el marcador de puntuación. ➔  Implementar diferentes niveles y dificultades en el juego. o  Implementar el cambio de nivel. o  Implementar la cantidad de vidas de pacman. o  Implementar la velocidad de los fantasmas. ➔  Implementar un servicio de registro en línea. o  Implementar la página de registro. o  Implementar el comprobador de acceso. ➔  Configurar un ejecutable para que se pueda descargar online. online. o  Compilar el juego en ejecutable .jar o  Crear enlace de descarga. o  Implementar página de descarga con acceso registrado. o

  Implementar página de login de usuario registrado. ➔  Implementar un base base de datos para para registrar y guardar el nombre de los participantes. o  Implementar una base de datos con ObjectDB. o  Implementar las clases de Usuario y DatosUsuario. o  Implementar el control de acceso. o  Implementar las “Query” adecuadas para:  ▪  Consultar usuario. ▪  Comprobar contraseña. ▪  Comprobar puntuación máxima. ➔  Implementar una página online que muestre los nombres, puntuaciones de los logros de los participantes. o  Implementar página de presentación de juego. o  Implementar página página de puntuaciones con acceso a la base de datos en tiempo real. o

➔ 

  Implementar listado con nombres y puntaciones. Editar un manual de instrucciones.

[NOMBRE DEL ALUMNO] [CICLO]  

PÁGINA 6

 

  Diagrama de las fases del proyecto:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 7

 

  ▪ 

Recursos hardware y software.

Requisit Re quisit os hardware: Generales a todos los integrantes del proyecto serán: Servidor para conectar todos los PC y distribuir la conexión y almacenar la información. Impresora con conexión a red común para todos. Conexión a internet de banda ancha. Ordenador PC con: Procesador de generación actual (AMD Ryzen 7). Memoria SDRAM DDR4 3733MHZ x 64GB. Placa Base con chipset AM4 X570. Tarjeta gráfica GTX 3080 o similar. Almacenamiento NVMe 1TB – Arranque y programas. Monitor 4k 32” IPS x 3ud. Teclado mecánico. Ratón + Alfombrilla. En cuanto a los requisitos particulares: Los programadores DAM utilizarán periféricos de juego (Mando y componentes VR).

El programador DAW utilizará tarjeta digitalizadora de formato A4 y escáner digital. El contable y administrativo tendrán una impresora propia.

Requisitos software: Generales a todos los integrantes del proyecto serán: S.O. Windows 10 Pro. Office 365. En cuanto a los requisitos particulares: Para los programadores DAM: IDE IntelliJ Idea. Plataforma JAVA (JDK, JRE, JVM) version 1.8. Controladores ObjectDB 2.8.5 para la BDD. NotePad++. Para el programador DAW:  Adobe Dreamweaver. IDE Apache NetBeans. Servidor remoto GlassFish 5.0. Plataforma JavaEE. NotePad++. Para el gerente, contable y el administrativo: a dministrativo: Dynamics 365. GANTT Project. [NOMBRE DEL ALUMNO] [CICLO] 

 

  ▪ 

Recursos materiales y personales.

Recurso Re curso s materiales: Oficinas como contenedor del personal y resto de continente. Maquinaria de Aire Acondicionado para el mantenimiento del servidor. Maquinaria de Aire Acondicionado para el mantenimiento del personal. Mesas de trabajo x 8ud. Mesa de reuniones x 1ud. Mesa de descanso comunitaria x 1ud. Sillas de oficina x 8ud. Sillas para reuniones x 10ud. Sillas de descanso x 6ud. Centralita de teléfonos x 1ud. Teléfono sobremesa x 8ud.  Archivadores personales x 8ud.  Armarios para almacenar documentación x 4ud. Máquina de refrescos x 1ud. Máquina de café x 1ud. Enchufes para los equipos informáticos y lámparas. Regletas RJ45 para redes. Pequeño utillaje de oficina (papel, bolígrafos, carpetas…).  Lámparas de mesa x 8ud. Lámparas de techo.

PÁGINA 8

Percheros x 2ud.

Recursos personales: Gerente. Programador Senior como jefe de departamento. Programador DAM x 2. Programador ASIR. Programador DAW. Contable.  Administrativo. Personal de limpieza ajeno a la empresa.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 9

 

 

1.3 3 Asp Aspectos ectos fis fiscales cales y labor laborale aless 1. ▪ 

Obligaciones fiscales, llaborales aborales y de prevención de riesgos laborales.

Obligaciones fiscales y labor ales: La empresa está inscrita de forma obligatoria en el Registro Mercantil. Como es una sociedad colectiva distinguimos dos tipos de socios, los industriales y los colectivos. Los socios colectivos son el gerente y el contable, por lo que tienen responsabilidad subsidiaria, solidaria e ilimitada. El jefe de departamento es socio industrial, por lo que sólo aportan trabajo y no tienen responsabilidad en la gestión, aunque si que se ha pactado aportar fondos para cubrir perdidas, si las hubiera. Todos los socios deben tributar con el Impuesto de Sociedades (IS) al 35% y están inscritos en el régimen de autónomos. Como autónomos los socios están obligados a tributar por las siguientes:  

Cuota de autónomo (Seguridad Social) : Fija y que asciende a 364.22 € por ser societarios. 

 

Pago del IVA: Este pago lo realiza la empresa trimestralmente presentando el modelo

• •

303, además, se presenta anualmente con el modelo 390.  

•

Impuesto del IRPF: Como los socios llevan más de dos años pagan una tributación del

15% pagándose, al igual que el IVA, trimestralmente en forma de Régimen de Estimación Directa Normal con el modelo 131, y regularizándose de forma anual en la Declaración de la renta presentando el modelo 100. En cuanto al capital que aportan los socios capitalistas, no existe un mínimo, así que se ha aportado lo que se ha convenido para poder poner en marcha la empresa. El resto de los trabajadores lo son por cuenta ajena contratados por la empresa. Las obligaciones fiscales para con los trabajadores son:  

Impuesto del IRPF: Aplicado en la nómina de forma mensual y que se actualiza anualmente a través del modelo 145, regularizando la situación s ituación anualmente a través de la Declaración de la Renta. El porcentaje aplicado dependerá del tramo de cotización. En nuestro caso tanto los informáticos como el ad ministrativo están en el tramo de 20.200€ a 35.200€ por lo que se hace una retención del 15% de tipo estatal y 15% de tipo autonómico, en total un 30%.

 

Seguridad Social: Cotizando en el Régimen General se pagan por diferentes coberturas:

•

•

o

    o  o  o  o

Contingencias Comunes: Formación Profesional: Desempleo: AT y EP: FO.GA.SA:

[NOMBRE DEL ALUMNO] [CICLO] 

4.70% trabajador 0.10% trabajador 1.55% trabajador 0% trabajador 0% trabajador

23.60% empresa 0.20% empresa 5.50% empresa 1.50% empresa 0.10% empresa

PÁGINA 10

 

 

Obligaciones en prevenció prevenció n de riesgos laborales: Se ha contratado un servicio de prevención ajeno para desarrollar el plan de prevención de riesgos laborales de la empresa. La empresa de prevención ajena también evalúa los riesgos y planifica la prevención, realizando la evaluación de riesgos  de los puestos de trabajo, aportando posteriormente la información necesaria al trabajador designado, en este caso el jefe de departamento. Asimismo, la empresa de prevención realiza la planificación de la actividad preventiva y aporta las indicaciones, planos y documentación necesaria. El trabajador designado se encarga de informar a los trabajadores  respecto a sus riesgos en el trabajo y sobre las medidas o actividades para prevenirlos, especialmente se s e han adoptado medidas en caso de emergencia  y ante riesgo grave e inminente, pero es la empresa de prevención ajena quien se encarga de formar a los trabajadores.   La vigilancia de la salud también esta a cargo de la empresa de prevención de riesgos laborales, en función del puesto de cada uno.

1. 1.4 4 Viabilid Viabilidad ad económ económica ica ▪ 

Financiación necesaria.

La empresa realiza diferentes proyectos simultáneamente, por lo que se va financiando por objetivos de proyectos.  A parte de la financiación privada por objetivos, la empresa empresa realiza proyectos independientes financiados con ayudas públicas proporcionadas por AEVI (Asociación Española de Videojuegos) que al igual que la financiación privada está condicionada por los hitos de entrega. Estos objetivos coinciden en ambos casos de la siguiente forma: El 25% del importe al comienzo del proyecto. El 25% del importe restante cuando se presente el e l Alpha del proyecto. El 25% del importe restante cuando se presente la Beta. El 25% del importe restante cuando se presente el e l Gold Master.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 11

 

  ▪ 

Presupuesto económico del proyecto:

Costo de Inmovi l izado materi al : Oficinas

Costo

T. amortización

T. uso

%

 

Aplicable

245.000,00 €

 

9.125 d

80 d

70,00%

1.503,56 €

Mobiliario

25.000,00 €

 

3.650 d

80 d

80,00%

438,36 €

Maquinas AA

52.000,00 €

 

3.650 d

80 d

70,00%

797,81 €

Equipos informáticos

36.000,00 €

 

1.460 d

80 d

80,00%

1.578,08 €

500,00 €

 

1.095 d

80 d

60,00%

21,92 €

365 d

80 d

60,00%

263,01 €

1.825 d

80 d

80,00%

280,55 €

Pequeños electrodomésticos Utillaje

 

2.000,00 €

Costo de Inmovilizado inmaterial: Programas

8.000,00 €

 

Costo de Personal: Gerente

6.000,00 €

 

30 d

80 d

35,00%

5.600,00 €

Contable

6.000,00 €

 

30 d

80 d

35,00%

5.600,00 €

Administrativo

2.500,00 €

 

30 d

80 d

35,00%

2.333,33 €

Jefe de sección sección

3.500,00 €

 

30 d

80 d

60,00%

5.600,00 €

Informático DAM

2.500,00 €

 

30 d

80 d

10 100,00%

6.666,67 €

Informático DAM

2.500,00 €

 

30 d

80 d

10 100,00%

6.666,67 €

Informático DAW

2.500,00 €

 

30 d

80 d

50,00%

3.333,33 €

Informático ASIR

2.500,00 €

 

30 d

80 d

20,00%

1.333,33 €

900,00 €

 

30 d

80 d

65,00%

1.560,00 €

Agua

120,00 €

 

30 d

80 d

80,00%

256,00 €

Luz

350,00 €

 

30 d

80 d

80,00%

746,67 €

Internet

120,00 €

 

30 d

80 d

80,00%

256,00 €

Teléfono

400,00 €

 

30 d

80 d

50,00%

533,33 €

Subscriciones varias

500,00 €

 

30 d

80 d

50,00%

666,67 €

Limpieza Costos fijos:

Costes fijos del proyecto proyecto Beneficios

46.035,29 € 

30,00%

Total sin I.V.A. I.V.A.. I.V.A

TOTAL PRESUPUESTO

13.810,59 €  59.845,87 € 

21, 1,00 00% %

12.567,63 € 

72.413,51 €

 

Para el cálculo se ha considerado el periodo de amortización en días y a continuación se ha aplicado el porcentaje de dedicación al proyecto medio por día para calcular el coste diario, d iario, todo ello multiplicado por el tiempo de desarrollo que en total se ha considerado de 80 días.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 12

 

 

1.5 5 Modelo de sol soluci ución ón 1. ▪ 

Modelado de la solución: Diagrama de casos de uso de la página Web

Diagrama de casos de uso del registro online

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 13

 

  Modelado E/R de BBDD

nombre alias apellidos

email

alias

fecha_registro

Usuario

proporciona

DatosDeJuego

puntuacion

tiempo_de_juego

Diagrama de casos de uso del videojuego PAC-MAN

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 14

 

  Diagrama de Clases del videojuego

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 15

 

 

2.Ejecució jecución n del proy p roye ecto y pru prueba ebass 2.1 2. 1 Riesgos de ejecució ejecución n del pro proyecto yecto ▪ 

Identificación de riesgos riesgos  del proyecto. proyecto.

Podemos identificar dos tipos de riesgo posibles, personales y materiales. En cuanto a los riesgos personales  tenemos: Posible estado de discontinuidad con la actuación de un trabajador en la ejecución de las tareas encomendadas en el proyecto. Esta discontinuidad puede estar ocasionada por: Falta de previsión de tiempo Baja o despido del trabajador Un incremento puntual de carga de trabajo. materiales s  tenemos: En cuanto a los riesgos materiale

Posibles fallos en los equipos informáticos debidos a rotura, desconfiguración, desactualización. Posibles fallos en el suministro eléctrico que pueda crear errores o demoras. Posibles riesgos de siniestros en las oficinas por incendio, inundación, etc. debido a desastres

naturales. Posible pérdida de datos por cualquier cuestión relacionada con los riesgos anteriores. ▪ 

Creación de plan de prevención de riesgos.

 Ante estas eventualidades recurrimos al siguiente plan de prevención: ales s: Para la prevención de riesgos person ale

 A la hora de presupuestar y planificar el proyecto se tienen en cuenta un porcentaje de días perdidos por cada trabajador. Por baja o despido, se tiene información disponible de posibles candidatos con experiencia para una sustitución temporal, así como un esquema detallado de los procesos de ejecución que se van realizando y todo aquello que queda pendiente. Por un incremento puntual de carga de trabajo se recurre a una ampliación máxima del horario de trabajo de una hora al día durante 15 días, pasado este tiempo se considera la contratación de un nuevo recurso para reforzar la plantilla. materiales s: Para la prevención de riesgos materiale

Todo el proceso de trabajo pasa a través de los servidores de la empresa. Estos servidores realizan copias de seguridad diaria de todo el trabajo, tanto físicamente como virtualmente, de forma que, en un momento puntual, se pudiera teletrabajar sin tener que acudir a las oficinas. Todo el sistema informático posee SAI para que no haya apagones inesperados. [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 16

 

 

2.2 2 Documentaci Documentación ón de ejecució ejecución n 2. ▪ 

Ejecución del proyecto.

El presente proyecto se divide en tres partes claramente diferenciadas que son: 1.- Programa del video juego Pac-Man 2.- Servidor que mantiene la base de datos donde se almacenan los datos de juego de los usuarios y que al mismo tiempo proporciona información a las páginas web para el registro, login y lista de máximas puntuaciones. 3.- Páginas web para la presentación del video juego, manual, lista de máximas puntuaciones, registro, login y página con enlace de descarga.

1. PROGRAMA PROGRAMACIÓN CIÓN DEL VIDEO VIDEO JUEGO PAC-MAN La programación del Pac-Man se ha realizado con el IDE IntellyJ IDEA, sin necesidad de ninguna librería externa aparte de las propias del JDK de Java 1.8.0_281. Como ayuda en el control de versiones hemos utilizado Git-Hub: Git -Hub:

Podemos ver una de las últimas revisiones subidas:

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Y la última revisión subida al repositorio:

Resultado de commit & push:

PÁGINA 17

Gracias al control de versiones se ha podido volver atrás cuando el desarrollo de una clase o implementación de un método no ha sido el adecuado. Además, nos hemos asegurado de no perder los datos en caso de un fallo físico del PC.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 18

 

  La elaboración del videojuego ha comenzado por la implementación de la clase principal LienzoPantalla.java que enlaza con todas las demás clases y sirve de lienzo. Esta clase es la que invoca el JPanel sobre la que se dibujan todos los objetos, la que instancia una clase privada para controlar los eventos ‘keyEvent’ de teclado, inicia el reloj con una instancia del objeto ‘Timer ’ que controla los tiempos del juego e implementa el método ‘actionPerformed’ que controla el dibujado y actualización de todos los elementos del juego.

Una vez tenemos la clase de enlace comenzamos dibujando la pantalla del juego, que se compone de una clase principal llamada ‘Pantalla.java’: 

Esta clase instancia objetos de clase PantallaDibujo.java, PantallaLimites.java y PantallaPuntos.java, pasándoles el valor de las variables necesarias para crear en primer lugar las paredes del laberinto del juego. Realmente PantallaDibujo no necesita ningún parámetro, puesto que todas las pantallas de PacMan son iguales, por lo que sólo invoca los polígonos que contiene para dibujarlos en el JPanel con un objeto Graphics2D que le ha sido pasado por LienzoPantalla. [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 19

 

 

Vemos como la clase PantallaDibujo.java consiste en un ArrayList que como hemos dicho, instanciará Pantalla.java para dibujarlos.

PantallaPuntos.java funciona de la misma forma, sólo que está compuesta por un ArrayList, estos puntos son creados instanciando la clase Punto.java que define el e l tamaño y posición de los puntos que aparecen en pantalla, mostramos el contenido de la clase PantallaPuntos.java:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 20

 

  Y la clase Pellet.java, crea dos tipos de puntos, los pellets normales y los PowerPellets que son más grandes:

Podemos ver el resultado preliminar, sin pellets, con pellets y aun sin fantasmas:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 21

 

  Pasamos a implementar la parte del marcador y los mensajes que aparecen en pantalla, en resumen, en toda la parte donde aparezca algo de texto como información al usuario. Para ello implementamos la clase PantallaTexto.java. Esta clase también es instanciada por la clase principal LienzoPantalla.java, y contine, como hemos dicho, la Fuente que se utiliza para el marcador y los textos, igual que la del juego original:

También contiene el método para la presentación del marcador del juego:

La información mostrada son la puntuación actual, el nombre del usuario (en esta pantalla es PACMAN) la máxima puntuación obtenida por el usuario y el número nú mero de pantalla:

Esta clase también dibuja el menú del juego cuando LienzoPantallla.java se lo solicita, es decir, cuando se inicia el juego o cuando se termina una partida por que se le terminan las vidas a PacMan:

Y la pantalla de menú en la clase PantallaTexto.java: [NOMBRE DEL ALUMNO] [CICLO] 

 

 

Podemos ver la pantalla de menú una vez iniciado i niciado el juego:

PÁGINA 22

Como en todo lo relacionado con el juego se ha intentado respetar el original dentro de lo posible, aun que en este caso vemos como en el pie de pantalla están reflejadas las opciones de dificultad del juego y la opción de salir que comentaremos más adelante.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 23

 

  Es la hora de implementar los objetos que interactúan con nuestro entorno, en este caso, PacMan y los fantasmas. Este punto se ha modificado varias veces hasta que se ha conseguido un movimiento adecuado, tanto de PacMan como de los Fantasmas, ya que al principio todos los movimientos se centraban en la detección de colisiones con el entorno, y nuestros personajes respondían a este, pero daba muchas inconsistencias, puesto que la anchura de los pasillos hacia que los personajes pudiesen desplazarse lateralmente dentro del pasillo, cosa que no ocurre en el PacMan original, si no que más bien los lo s personajes tienden a ir como guiados por unos carriles. Para conseguir este efecto se ha creado un nuevo package llamado ‘camino’ y dentro hemos creado las clases Punto.java, que es la responsable de guardar las coordenadas X e Y de los puntos que conforman con forman las líneas a forma de carril por donde pasarán los personajes. Esta clase también contiene unos métodos internos que le dan nombre al punto dependiendo de su posición en referencia a la fila y columna que se encuentre. Más adelante explicare exp licare el motivo.

Tenemos la clase Linea.java, definida por dos puntos, un punto inicial, y un punto final. Además, esta clase calcula y almacena el ‘peso’ o distancia entre los dos puntos . Contiene un método que calcula si un punto que se le pase como parámetro está contenido en la línea y en ese caso cuál es el punto del extremo más cercano. También tenemos la clase ColeccionLineas.java que crea una Lista con todas las líneas que definen el laberinto del juego. Y finalmente dentro de este package tenemos la clase PantallaCamino.java, al que se le pasa una posición X e Y y una velocidad en X y en Y y devuelve la posición siguiente. Esta clase es la que fuerza a los personajes a ir por dentro de los pasillos, sin opción a salirse de ellos.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 24

 

  La clase PacMan controla todo lo que tiene que ver con su personaje, por lo tanto, tiene que controlar el movimiento, la visualización del personaje invocando el icono que lo representa, los pellets y fantasmas que se va comiendo para además sumar la puntuación, puntuac ión, las vidas que tiene y si el e l personaje muere. También controla la posición de PacMan en pantalla según detecta los eventos de teclado que le pasa la clase privada TAdapter() de LienzoPantalla.java. PacMan es instanciado por LienzoPantalla.java y actualizado mediante el método actionPerformed, redibujándolo en cada golpe del timer, de esta forma se crea la sensación de movimiento:

Vemos como cada vez que se detecta una acción concreta cambia la ‘velocidad’ o posición de PacMan.  Los diferentes iconos que utiliza PacMan para su visualización:

Los fantasmas funcionan de la misma forma que PacMan, pero con la diferencia de que son autónomos, es decir, se mueven solos y además tienen personalidad propia. pro pia. Esta parte del proyecto también se ha modificado completamente y es la que más me gusta. Originalmente los fantasmas actuaban con el entorno igual que PacMan, es decir, que no sabían como llegar a PacMan, solamente se dedicaban a intentar llegar a el y cuando ‘chocaban’ con un obstáculo intentaban evitarlo. Esto hacía que la búsqueda de PacMan resultara muy ineficiente, además que a veces se producían errores en las colisiones y los fantasmas acababan atrapados en una esquina o incluso se salían del laberinto flotando por el exterior de la pantalla. Para arreglar esto, cuando comencé a construir la nueva implementación de desplazarse de PacMan a través de ‘carriles’ se me ocurrió que podía construir el laberinto como un grafo cerrado y realizar una búsqueda utilizando del camino más corto utilizando el algoritmo de Dijkstra. Así pues, aprovechando que tenía los puntos y las líneas, además del peso de las aristas construí dentro del package ‘grafoBusqueda’ las clases Vertice.java, que contiene la posición de un punto equivalente a los puntos del camino de PacMan, pero que a su vez contienen una lista con los puntos adyacentes, así como los métodos para desplazarse entre ellos. La clase Vertice.java que contiene un Vertice destino y el peso de la arista. [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 25

 

  La clase Camino.java que compara el peso que hay entre un camino para ir a un vértice u otro. La clase CrearGrafo.java, que recoge la lista de líneas que se crea para PacMan y las añade a ñade al grafo que creamos para la búsqueda. Y finalmente la clase Grafo, que contiene el grafo creado y que, al pasarle un nodo de origen y otro de destino, nos devuelve el camino más corto. Por fin nuestros fantasmas ya tienen una forma eficiente de encontrar a PacMan. El método búsquedaCamino() de la clase Fantasmas.java se encarga, ayudado del grafo, de pasarle los parámetros de los fantasmas y de PacMan y recoger los nodos, uno por uno, que tienen que recorrer y el orden que tienen que seguir. Esta búsqueda se está realizando a cada golpe de timer, por lo que se actualiza constantemente:

Ni los fantasmas ni PacMan, permanecen nunca en un nodo concreto, si no que están ubicados u bicados en la arista o línea, así que utilizamos el método de d e la clase Linea.java, linea.contiene(punto) y a continuación asignamos el punto del extremo de la línea más cercano linea.nodoMasCercano(punto) que SI corresponde con un nodo.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 26

 

  Una vez la búsqueda de PacMan está solucionada falta crear el movimiento personalizado de cada uno de los fantasmas, por ejemplo en el caso de Inky, que sólo persigue a PacMan si Pinky y Blinky están lo suficientemente cerca:

Cabe destacar que este método también se utiliza cuando PacMan se come un PowerPellet y los fan-

tasmas tienen que huir, que se les asigna un destino alejado de él, o cuando son devorados por PacMan y tiene que volver a casa para regenerarse. Los personajes tienen un punto de partida, que están obligados a declarar por la clase que heredan MovimientoPersonajes.java. Una vez declarados todos los parámetros podemos ver cómo queda:

Nuestro PacMan ya tiene un aspecto más decente. [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 27

 

  Para que PacMan pueda comerse los puntos se ha implementado el método checkCollisionsPoints() que está dentro de la clase PacMan.java, este método recoge el ArrayList que le pasa LienzoPantalla.java, y mediante el método de java getBounds() detecta una colisión con cualquiera de los puntos y en ese caso lo elimina del array:

Como podemos ver este método también activa el poder de PacMan cuando se come un PowerPellet y en ese caso informa a LienzoPantalla.java que a su vez informa a las instancias de los fantasmas para que actúen en consecuencia.

De la misma forma que PacMan, los fantasmas también implementan en la superclase Fantasmas.java el método checkCollisions() que de igual modo utilizan una instancia de getBounds() con su método .intersects() para detectar la colisión con PacMan, y dependiendo del estado del fantasma la clase actúa en consecuencia, puesto que no es lo mismo que el fantasma este persiguiendo a PacMan o que esté huyendo de él:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 28

 

  Como hemos dicho, todas estas acciones se van actualizando a golpe de timer en el método actionPerformed de LienzoPantalla.java:

Como vemos hemos encapsulado las acciones que realizan dentro de otros métodos para un mejor mantenimiento. Una vez construidas las clases principales se ha añadido la clase Premios.java. Esta clase controla la visualización y la puntuación de los premios especiales de cada pantalla. Dependiendo de los puntos que se va comiendo PacMan van apareciendo debajo de la casa de los fantasmas:

Vemos que cada 70 y cada 190 pellets aparecen los premios. El tipo de premio también depende del número de pantalla en la que se encuentre PacMan. Los premios también aparecen de forma temporal, de forma que si PacMan no se los come en 10 segundos desaparecen:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 29

 

  También contiene los puntos que vale cada uno de los premios. Otra de las funciones exigidas es una tecla de pausa que se ha implementado dentro de la clase LienzoPantalla.java:

Como vemos se ha detenido la ejecución del reloj ante un evento de teclado (pulsar la tecla ‘p’) . Tanto PacMan como los fantasmas no se activan inmediatamente al inicio del juego, PacMan se inicia cuando el contador termina, y los fantasmas se activan cuando pasa cierto tiempo desde el inicio:

Estos tiempos se declaran en el constructor de la clase LienzoPantalla.java:

Una vez tenemos un juego funcional pasamos a implementar los requisitos mínimos exigidos por el cliente que aún no están en funcionamiento. Se tiene que poder elegir la dificultad del juego, así que se ha creado la opción en el menú entre fácil y difícil, para ello en la clase de PacMan.java se ha incluido el método setDificultadFacil():

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 30

 

 

vidas , tiene más o menos velocidad y el  Así dependiendo de la dificultad, PacMan tiene más vidas, e l tiempo que dura el poder es mayor o menor. También se ha implementado la opción de seguir con más pantallas, y al igual que en el juego original or iginal se tienen que resetear los personajes y los puntos de pantalla. LienzoPantalla.java controla mediante la opción de nuevoNivel si PacMan se ha comido todos los pellets de la pantalla, cuando sucede PacMan devuelve true mediante el método nuevoNivel() y LienzoPantalla.java L ienzoPantalla.java ejecuta el método nuevoNivel():

Como se puede ver este método invoca otros diferentes que resetea la posición de los personajes, personajes , rellena de nuevo la pantalla de puntos, incrementa el nivel de la pantalla, reinicia el tiempo y los pellets comidos. Para la cantidad de vidas de PacMan la clase de PacMan.java contiene la variable int vidasDePacMan, que controla la cantidad de vidas que le quedan, cada vez que un fantasma colisiona con el se el quita una vida, y cuando llega a 0 se reinicia el juego, esto se controla con el método quitarVida():

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 31

 

  LienzoPantalla.java controla el valor de finDeJuego mediante el método getFinDeJuego() y cuando devuelve true se resetean todo y aparece el menú del juego. Sobre la implementación de la velocidad de los fantasmas, en la clase fantasma se asigna a las variavari ables velocidadMinima, velocidadNormal y velocidadMaxima valores diferentes. Blinky, en su método controlarVelocidad() controla la velocidad del movimiento dependiendo de los pellets que se ha comido PacMan:

Por último, como necesidades de cliente, se ha implementado la posibilidad de registrar la puntuación obtenida, de forma que si está entre la mejores aparezca en el listado de la página web. Para esta función se han programado tres clases. La primera de ella controla los datos de juego llamada DatosDeJuego.java obtenidos desde el juego, como son la puntuación y el tiempo de juego, además del alias del usuario. Esta clase tiene estos tres atributos que recaban la información y la guardan en el archivo datosUsuarios.dat

 Al mismo tiempo, esta clase lee el archivo y le pasa la información de nombre de usuario y puntuación máxima a LienzoPantalla.java, de esta forma al usuario siempre le aparece en pantalla la máxima puntuación obtenida. En caso de que el archivo de datos no exista, se invoca una interfaz de usuario que pide el alias para crear uno nuevo:

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Vemos la interfaz creada:

Por seguridad se han realizado dos comprobaciones adicionales:

El actionPerformed de la clase DatosUsuarioGUI:

PÁGINA 32

El form de DatosUsuariosGUI:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 33

 

  Las otras dos clases, están dentro del Package clienteConexión, y controlan el acceso al servidor para enviarle la información del usuario. Estas clases se activan cuando el usuario pulsa pu lsa la tecla (s) de salir del  juego desde el menú de la la pantalla. En ese momento la clase LienzoPantalla.java llama llama al método enviarDatos(), este método crea una instancia de la clase Cliente.java:

La clase Cliente.java invoca la clase DatosUsuario.java para leer los datos almacenados en el archivo, y a continuación crea una instancia de Conexión.java para conectar con el servidor y enviar los datos:

La clase Conexión.java utiliza un Socket para enlazar con el servidor y enviar los datos:

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Una vez creados los sockets y establecida la conexión con el servidor envía los datos:

PÁGINA 34

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 35

 

 

2. SERVIDOR DE BA BASE SE DE DATOS

La segunda parte del proyecto ha sido la creación del servidor y la base de datos. La primera clase que se ha creado es la de IncioServidor.java que contiene el método main e invoca una instancia del servidor. Para la creación del servidor hemos utilizado la clase c lase ServerSocketFactory. En este punto voy a destacar que en principio había utilizado la clase SSLServerSocketFactory para realizar comunicaciones seguras entre el servidor y los clientes. Incluso había generado las claves de validación para los clientes, pero cuando implementé la página pá gina web y comencé las pruebas pru ebas de comunicación con GlassFish me saltaba un error de seguridad SSL. Investigando un poco pude comprobar que la versión que estaba utilizando de GlassFish tenia un error en la librería ‘grizzly-npn-bootstrap.jar’ y no dejaba efectuar ese tipo de comunicaciones, por lo que después de intentar actualizar la librería sin éxito, decidí cambiar el tipo de comunicación por el ServerSocketFactory. Siguiendo con la creación del servidor, tenemos la clase Servidor.java que inicia el socket para recibir las comunicaciones y una vez iniciada ejecutamos un bucle ‘while’ que se queda a la escucha esperando nuevos clientes y en el caso de recibir rec ibir un cliente se introduce en un u n ArrayList:

El servidor no permite más de 10 conexiones simultáneas, por lo que llegado el caso, no admite más clientes.  A continuación, tenemos la clase ServerController.java que es la que inicia la base de datos, controla la entrada de ordenes por consola. El servidor sólo admite una orden por consola y es ‘desconectar’ para detener el servidor. Esta clase está declarada como final por dos motivos. Primero, por que sólo puede haber un controlador de servidor por servidor, de esta forma nos n os evitamos conflictos, y segundo por que sólo hay que instanciar una base de datos, y se instancia en la creación de esta misma clase que es única.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 36

 

 

De la parte concreta del funcionamiento del servidor, nos queda la clase Cliente.java. Esta clase se instancia cuando se conecta un nuevo cliente y es la que se pone a la espera de recibir los comandos del cliente.  Al instanciar esta clase se crea un nuevo hilo de ejecución, por lo que extiende la clase Thread y sobrescribe el método run(), siendo este método el que recibe los comandos del cliente:

Estos comandos están directamente relacionados con la base de datos, y se pueden utilizar indistintamente, aunque están diseñados para que la parte del video juego de PacMan al comunicarse con el [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 37

 

  servidor, sólo utilice el comando ‘actualizarDatosJuego’ mientras que los otros comandos es tán reservados para la comunicación con la web. Estos comandos ejecutan los métodos adecuados para responder al cliente e interactuar con la base de datos y como están ejecutándose en hilos distintos utilizamos la palabra reservada ‘synchronized’ para que no haya fallos e inconsistencias a la hora de acceder a la base de datos en el caso de que varios clientes se comunique con ella simultáneamente.

Una vez terminado el servidor, pasamos a la base de datos. Se ha utilizado un base de datos objeto-relacional. En este caso ObjectDB, puesto que se ha considerado la velocidad de acceso a la misma. La facilidad de creación y mantenimiento, puesto que sólo utilizamos la librería de ObjetcDB.jar y creamos un único archivo que contiene todos nuestros datos. Además, es

gratuito, existe mucha documentación en la web y está en constante desarrollo. Como hemos dicho, para la creación hemos integrado en nuestro proyecto de servidor la librería ObjectDB.jar:

Para el control de la base de datos tenemos tres clases, DatosDeJuego.java, Usuario.java y OdbPacManController.java. Las dos primeras clases, DatosDeJuego.java y Usuario.java son las clases que utiliza la base de datos [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 38

 

  como objetos persistentes de tipo clase, para almacenar los datos y contener los métodos de acceso a esos datos. Podemos ver como son declarados como @Entity, conteniendo un @Id y generando un u n @GeneratedValue para identificarlos:

 Al ser clases contenedoras, contenedoras, su implementación es trivial, ciñéndose a la declaración de los atributos y los métodos get y ser de estos. En cuanto a la clase OdbPacManController.java es más compleja, puesto que es la que crea el archivo

de base de datos, en este caso ‘pacMan.odb’  y la que maneja los objetos en la librería, así como la que realiza las consultas que se le piden y responde al cliente. Para manejar los objetos, la clase instancia los objetos de la librería propia de objectDB, EntityManagerFactory y EntityManager, el primero para abrir el archivo y crear la persistencia de datos y cerrar el archivo cuando no se necesita:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 39

 

  El segundo nos permite manejar los objetos y crear la ‘Query’ :

En este caso, vemos cómo hacemos una consulta para comprobar si el usuario que se pasa como parámetro existe en la base de datos. Cada vez que se realiza una consulta o se manejan los datos de algún modo, hay que abrir y cerra el archivo de la base de datos. Para ellos nos aseguramos añadiendo en el bloque try  – catch la cláusula

finally  con el método que cierra el archivo. Esta clase contiene los métodos para crearUsuario(), setDatosDeJuego(), recogerListadoNombres(), comprobarUsuarioRegistrado() y comprobarPassword(), que corresponden con las ordenes que el cliente del servidor acepta.

3. PÁGINAS WEB Para la realización y las pruebas de las páginas web se ha utilizado el IDE Apache NetBeans 12.0 y el servidor GlassFish 5.0 para las pruebas. Este apartado también podemos dividirlo en otros dos, el de comunicación con el servidor de la base de datos por un lado y las páginas Web por otro. Como en el caso del PacMan, la parte de conexión del servidor serv idor se ha programado en Java, teniendo dos clases, la clase Conexión.java y la clase Cliente.java. La clase Conexión java es la que se comunica directamente con el servidor y al igual que su homóloga en PacMan, contiene la clase SocketFactory y Socket para realizar rea lizar esa función:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 40

 

  Esta clase contiene los métodos necesarios para pedir los datos de comprobarPassword(), crearUsuario(), comprobarUsuarioRegistrado() y listaNombres() para poder verificar los datos que van a solicitarse a través de la web, y es la clase Cliente.java la que enlaza entre los servlets del servidor web y la clase Conexion.java al instanciarse desde los mismos servlets. Las tres operaciones que realiza realmente la clase Cliente.java:

Estos métodos ya se encargan de comprobar si se puede o no crear un usuario, pidiendo la información necesaria para ver si el usuario existe, si la conexión se ha realizado, si la contraseña introducida coincide con el alias de usuario y finalmente también pasa un arreglo String[] con la lista de los 7 jugadores con mejor puntuación para mostrarla.

Por otra parte, tenemos la parte del servidor web, con el desarrollo de las páginas web, y con los servlets que sirven de puente entre las páginas .jsp y la clase Cliente.java. En este caso existen tres servlets, ServletActualizarLista.java, ServletLogin.java y ServletRegistro.java.

Para declarar un servlet tenemos que importar la librería de javax.servlet.http.HttpServlet, además de la librería tenemos que declararlo como tal en la declaración d eclaración de la clase y extender HttpServlet:

En este caso estamos declarando el ServletRegistro y su dirección de acceso. Nuestros servlets sobrescriben el método doPost() de la clase HttPServlet para comunicarse de forma interna con las páginas y que la información no se mande a través de una url, sino en el interior del mensaje. El ServletRegistro recoge los datos del formulario de registro para posteriormente instanciar la clase Cliente.java y obtener respuesta si ha sido posible o no crear el usuario:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 41

 

  La respuesta a la página se realiza a través del método HttpServletResponse:

El ServletLogin funciona de la misma forma, sólo que utiliza como datos el alias y la contraseña que le pasa el formulario de la web.

El SerletActualizaLista es un poco más complejo. Para comenzar, sobrescribe el método doGet(), aunque esto no es lo complejo, puesto que es el método por defecto que utilizan las páginas para la comunicación, pero en este caso la información transferida no es sensible y no importa el método de transmisión. Dentro del método doGet encontramos una llamada al método actualizaListado que instancia a Clinente.java para recoger un arreglo de String[] con la lista de los nombres y puntuaciones de los siete mejores que existen en la base de datos.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 42

 

   Aquí podemos observar que una vez obtiene la lista util utiliza iza el método .setAttribute() para pasar a la página la lista y a continuación el método .getRequestDispatcher() para redirigir los datos y el cambio de página a la que este método indica. En este caso ‘puntuacion.jsp’ . Pasamos ahora al funcionamiento de las páginas. Se ha utilizado el lenguaje de marcas html en combinación con el lenguaje interpretado JavaScript, de ahora en adelante JS. Para ello, las pagina se han nombrado con la extensión .jsp. Continuando con nuestro ServletActualizarLista.java nos dirigimos a la página lista.jsp. Esta página es a la que nos direccionamos desde el menú de navegación de las páginas web, pero para poder actualizar automáticamente el listado de los nombres tenemos los siguientes atributos declarados:

En primer lugar, hacemos un “ref resh resh” para actualizar la página, en segundo lugar declaramos el content=0 para que se refresque inmediatamente, y no tengamos que esperar, y en tercer lugar, la segunda parte de content llama al ServletActualizarLista que, como acabamos de comentar, actualiza los datos de la lista de nombres y nos redirige a la página puntuación.jsp, además de pasar esos datos en una lista.

Nuestra página puntuación.jsp, además del lenguaje JS utiliza la librería de ‘core’ y para ello la llamamos con:

Esta librería nos permitirá importar el atributo lista y realizar un forEach para recórrela:

Como podemos ver, importamos gracias al identificador var=“lista”   la lista en ítems=”${lista}” para finalmente recorrer todos sus elementos y mostrarlos.  Aparte de eso nuestra página incluye referencias jsp para importar botonesNavegación.jsp y pierDePagina.jsp. [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 43

 

  Gracias a esta característica de JS reutilizamos el código y ahorramos reescribir partes que se repiten. En nuestro caso, todas las botoneras y todos los ‘pie de página’ son comunes. Pasamos a la clase registro, que contiene el formulario f ormulario para registrar al usuario.

En este caso tenemos etiquetas label, indicando el nombre de cada campo, etiquetas input que instancian los cuadros que se tienen que rellenar y cada uno de ellos con su propia id y name para poder po der identificarlos cuando los enviemos al servlet.

 Además, incluimos el atributo required, para obligar o bligar a rellenar los campos y un atributo placeholder para mostrar un ejemplo de campo en cada uno de ellos. Cada campo está marcado como el tipo de contenido que va a registrar, type, teniendo “text”, “email” y “password” de esta forma el campo se comprueba y sólo admite el tipo de elemen tos permitidos.

Finalmente tenemos los botones tipo “submit” que envía la información de los campos, cam pos, siempre que estén rellenos adecuadamente y el tipo “reset” que elimina todos los valores que contiene.   Toda esta información se envía mediante el método method=”POST” al servlet action=”/WebServidorPacMan/SerletRegistro” y finalmente nos muestra la información de respuesta en una nueva página   target=”_blank”  La página login.jsp funciona de forma similar, sólo que al aceptar el registro, una vez que el ServletLogin.java lo ha comprobado, nos redirige a la página de descarga.jsp:

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 44

 

  Las páginas de index.jsp, manual.jsp y descarga.jsp, no tienen ninguna funcionalidad especial. En todo caso las dos últimas incluyen un enlace de descarga, para el manual y el juego respectivamente:

Para poder previsualizar las páginas tenemos que poner po ner en funcionamiento el servidor GlassFish:

 A continuación, hay que iniciar el servidor de la base de datos:

Una vez iniciados los servidores, compilamos el proyecto lo iniciamos, el resultado se visualiza en el navegador predeterminado.

[NOMBRE DEL ALUMNO] [CICLO] 

 

 

Podemos ver el resultado: El servidor de la base de datos iniciado esperando clientes:

PÁGINA 45

Página principal de PacMan:

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Página del Manual:

Listado de máximos puntuadores:

PÁGINA 46

Podemos observar como el servidor de la base de datos a aceptado la petición y le ha enviado el listado:

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Registrando un nuevo usuario:

PÁGINA 47

La página contesta afirmativamente:

El servidor de la base de datos a registrado el movimiento:

[NOMBRE DEL ALUMNO] [CICLO] 

 

   Ahora nos intentamos ‘Logear’ registrarnos sin éxito:

El servidor no ha aceptado nuestra solicitud:

Esta vez sí que hemos acertado con la contraseña:

PÁGINA 48

El servidor refleja el acceso:

[NOMBRE DEL ALUMNO] [CICLO] 

 

   Al pinchar el enlace nos abre la descarga:

PÁGINA 49

Desconectando el servidor de la base de datos:

▪ 

Manuales finales:   Manuales de usuario

o

El manual de usuario se adjunta al proyecto como ManualPacMan.pdf   Manuales de instalación

o

Ninguno de los programas requiere de instalación, solamente el video juego de Pac-Man requiere descomprimir el archivo zip que lo contiene, y este procedimiento se explica en el manual de instrucciones.   Manuales de Configuración y administración

o

No procede.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 50

 

 

2.3 Incidencias ▪ 

Definir un protocolo para resolución de incidencias:

Debido a la variedad del proyecto distinguimos los tipos de incidencia entre: Incidencias de conflictos en la ejecución del juego. Incidencias de red o acceso a Web. Incidencias de acceso a base de datos Incidencias en datos de usuario. Las incidencias de ejecución del juego se detectan y resuelven haciendo pruebas de ejecución en el juego y comprobando que los requisitos mínimos requeridos por el cliente cl iente se están cumpliendo. En caso de fallo fa llo se revisa el código analizando la clase o clases c lases afectadas. En caso de acceso a la red por fallo del servidor se ha implementado diferentes bloques de captura de fallos para trazar y seguir el fallo, pudiendo localizarlo fácilmente y solucionándolo mediante diferentes cambios en los métodos afectados. En caso de fallo de acceso a Web se revisa que el código generado esté correctamente validado por el IDE y que los enlaces de acceso a partes de d e los archivos .jsp estén bien definidos. Se revisa que el servidor funcione correctamente y se hacen pruebas de acceso.

En caso de fallo en acceso a base de datos se revisa que las ‘query’ implementadas sean correctas, se comprueba que el acceso al archivo se haya producido de forma correcta revisando el código de acceso al archivo .db y finalmente se comprueba que las búsquedas sin resultado no hagan fallar el programa. En caso de incidencias en el acceso a los datos de usuario se ha crea un modulo independiente de acceso que controla este acceso, de forma que si no se detecta se crean nuevos datos para que el programa pueda seguir ejecutándose.

[NOMBRE DEL ALUMNO] [CICLO] 

 

 

2.4 4 Pruebas y sop soport orte e 2. ▪ 

Registro de las pruebas realizadas:

1. PRUEBAS SOBRE EL VIDEO JUEGO PACMA PACMAN N Prueba de funcionalidad del menú. El menú se visualiza correctamente al iniciar el juego. Las teclas D, F y S responden adecuadamente:

PÁGINA 51

Cuando Pac-Man come pellets estos desaparecen. La puntuación se va sumando correctamente en el marcador. Los fantasmas se transforman cuando Pac-Man se come un Power Pellet y huyen. Pulsar la tecla ‘P’ pone el juego en pausa y lo indica en pantalla. El juego vuelve a funcionar al volver a pulsarla:

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Las teclas de dirección funcionan adecuadamente. PacMan atraviesa de forma correcta el paso de teletransporte. Pulsar cualquier otra tecla no tiene ningún efecto sobre el juego.  Al comer fantasmas, estos se transforman transforman y buscan regresar a su casa. Los fantasmas muertos no afectan a PacMan.  Al entrar en casa se regeneran. La puntuación de comer fantasmas se suma al marcador.

PÁGINA 52

Los premios van apareciendo conforme comemos pellets. Cuando comemos un premio, la imagen aparece en la pantalla. La velocidad de Blinky aumenta conforme PacMan se come los pellets. Cuando terminamos todos los puntos cambiamos de pantalla. La velocidad de Pac-Man aumenta al comer los Power Pellets.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 53

 

   Al cambiar de pantalla en número de pantalla se refleja en el marcador. Pac-Man no puede moverse hasta que la cuenta atrás a trás no termina. Los fantasmas van saliendo de su casa escalonadamente. Los fantasmas persiguen a Pac-Man y lo hacen de formas distintas. Excepto Clyde, que no lo persigue. Cuando Pac-Man muere se le restan las vidas. Cuando no le quedan vidas volvemos al menu. La máxima puntuación se conserva incluso al salir y vover a entrar en el juego.

 Al salir del juego se actualiza el servidor.

2. PRUE PRUEBAS BAS SOBRE EL SERVID SERVIDOR OR DE LA BASE BA SE DE DATOS El servidor se pone en funcionamiento de forma adecuada. El servidor admite clientes nuevos. El servidor admite peticiones de los usuarios. El servidor no procesa las peticiones que no están implementadas.

[NOMBRE DEL ALUMNO] [CICLO] 

 

  Los clientes se desconectan después de procesar la petición. El servidor procesa adecuadamente las peticiones de los clientes. En caso de una excepción el servidor la captura y sigue funcionando adecuadamente.

El servidor se desconecta de forma adecuada.

3. PRUE PRUEBAS BAS SOBRE LA PÁGINA PÁGINA WEB

PÁGINA 54

Las páginas web se visualizan correctamente. El menú de navegación funciona y nos redirige a las páginas solicitadas.

El usuario se puede registrar rellenando los campos correctamente. La página detecta usuarios duplicados.

El usuario puede acceder a la página de descarga usando las credenciales adecuadas y rechaza la petición en caso contrario. [NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 55

 

  Los enlaces de descarga del manual y descarga del juego funcionan adecuadamente.

La lista de usuarios con máxima puntuación se muestra al acceder a la página. La lista de usuarios con máxima puntuación se actualiza con los datos proporcionados por el servidor. s ervidor.

[NOMBRE DEL ALUMNO] [CICLO] 

PÁGINA 56