PARTE 1 — DOCUMENTACIÓN ORGANIZATIVA DEL PROYECTO

1.1Descripción general del proyecto

MiniJuegos es una aplicación de escritorio desarrollada en Java con interfaz gráfica Swing. Permite a varios usuarios registrados jugar partidas de minijuegos de forma individual o multijugador, pausar y reanudar partidas, y consultar un historial de estadísticas. Incluye además un panel de administración para usuarios con rol de administrador.

Stack tecnológico

• Lenguaje: Java SE (JDK 17+)
• Interfaz gráfica: Swing (javax.swing, java.awt)
• Persistencia: Ficheros de texto plano (.txt, .dat) en la carpeta data/
• Librerías externas: Ninguna — requisito explícito del enunciado
• Seguridad: SHA-256 (java.security.MessageDigest)

Juegos implementados

• Pasapalabra: rosco de 27 letras con 4 niveles de dificultad (Infantil, Fácil, Medio, Avanzado). El jugador dispone de 2 minutos 30 segundos para responder todas las definiciones.
• Tres en Raya: tablero 3×3 para dos jugadores con detección automática de victoria y empate.

1.2Requisitos del enunciado

• Aplicación de minijuegos con mínimo dos juegos distintos.
• Gestión de usuarios con registro, login y roles (usuario estándar / administrador).
• Persistencia en ficheros de texto sin librerías externas de base de datos.
• Arquitectura orientada a objetos: uso de herencia, polimorfismo, clases abstractas e interfaces.
• Interfaz gráfica con Swing.
• Historial de estadísticas por usuario y ranking global por juego.
• Posibilidad de pausar y reanudar partidas.
• Panel de administración accesible solo para usuarios admin.

1.3Arquitectura en capas

El sistema está organizado en cuatro capas bien diferenciadas ubicadas en paquetes Java independientes:

Vista (paquete Vista)

Contiene todas las ventanas y paneles Swing. Cada ventana es responsable de recoger la interacción del usuario y delegar la lógica en los gestores. No contiene reglas de negocio. Las clases son: Aplicacion, Tema, VentanaLogin, VentanaMenuPrincipal, VentanaSeleccionJuego, VentanaJuego (abstracta), VentanaJuegoPasapalabra, VentanaJuegoTresEnRaya, VentanaEstadisticas y VentanaAdmin.

Controladores (paquete Controlador)

Coordinan Vista con Modelo. Cada gestor cubre un dominio específico: GestorUsuarios (autenticación, registro, sesión), GestorJuegos (registro y creación de juegos), GestorPartidas (ciclo de vida de partidas: iniciar, pausar, reanudar, finalizar), GestorEstadisticas (registro y consulta de resultados).

Modelo (paquete Modelo)

Clases de dominio puras sin dependencias de UI ni de persistencia: Usuario (abstracta), Jugador, Administrador, Juego (abstracta), PasaPalabra, TresEnRaya, Partida, Estadistica, PuntuacionJugador y el enum EstadoPartida.

Persistencia (paquete Persistencia)

La interfaz GestorPersistencia define el contrato de acceso a datos (usuarios, estadísticas, partidas pausadas). La clase PersistenciaArchivos implementa ese contrato usando ficheros de texto en la carpeta data/. Esta separación permite cambiar el mecanismo de almacenamiento (p. ej. base de datos) sin modificar el resto del sistema.

1.4Decisiones de diseño tomadas y por qué

Juego es clase abstracta (no interfaz)

Todos los juegos comparten estado común (nombre, descripción, juegoFinalizado, listaPuntuacionPorJugador) y comportamiento concreto (sumarPuntos, getPuntuacion). Una interfaz no puede llevar estado. Los métodos abstractos (inicializar, getEstadoTexto, serializarEstado, deserializarEstado, terminar) obligan a cada subclase a implementar su mecánica propia.

Usuario abstracta con subclases Jugador y Administrador (en lugar de boolean esAdmin)

La decisión inicial era un campo esAdmin:boolean dentro de Usuario. En la implementación final se optó por polimorfismo real (instanceof Administrador) porque simplifica los condicionales en GestorUsuarios y VentanaAdmin, y facilita extender el sistema con más roles en el futuro sin modificar código existente.

GestorPersistencia es una interfaz

Permite cambiar de ficheros de texto a cualquier otra fuente de datos (base de datos relacional, XML, red) sin tocar ni los controladores ni la vista. Solo hay que proporcionar una nueva implementación de la interfaz.

Contraseñas almacenadas como hash SHA-256

Las contraseñas nunca se guardan en texto plano. La clase Usuario aplica SHA-256 internamente. El constructor alternativo (yaEsHash=true) permite reconstruir objetos desde disco sin volver a hashear.

PasaPalabra carga una pregunta aleatoria por letra de cada bloque de 10

Cada nivel tiene ~10 preguntas por letra. cargarDatos() elige una al azar en cada ejecución, lo que aumenta la rejugabilidad sin aumentar la complejidad del modelo.

Estado de partida pausada serializado en formato texto inline

El estado se serializa como una cadena única (ej. "TresEnRaya|user1,user2|casilla00,...") guardada en un fichero .dat por partida. Esto evita dependencias de serialización Java y hace el formato legible y fácil de depurar.

Gestores expuestos como campos estáticos desde Aplicacion

En lugar de inyectar los gestores en cada constructor de ventana (lo que sería más puro), se accede a ellos vía Aplicacion.getGestorX(). Simplifica el código de las ventanas y evita cadenas largas de parámetros en constructores, a costa de un acoplamiento mayor con la clase Aplicacion.

VentanaJuegoPasapalabra NO extiende VentanaJuego

Pasapalabra necesita lógica propia de temporizador y resumen final que difiere del ciclo estándar de accionFinalizar(). Se decidió que extender VentanaJuego añadiría más complejidad que valor. VentanaJuegoPasapalabra extiende directamente JFrame.

Atributos siempre private; protected solo donde la subclase lo necesita

Juego declara algunos atributos como protected (nombreJuego, descripcion, juegoFinalizado, listaPuntuacionPorJugador) porque TresEnRaya y PasaPalabra acceden directamente a ellos. El resto de clases usa private con getters/setters.

Clase Tema con constantes de diseño visual

Centraliza toda la paleta de colores y tipografía. Así, cambiar el aspecto visual de la aplicación requiere modificar un único fichero en lugar de buscar valores hardcodeados por todas las ventanas.

1.5Reparto de trabajo por integrante

JP Aceves

Coordinación general, arquitectura, modelo de partidas y persistencia.

Adrián Duque

Modelo de usuarios, juego Pasapalabra y vistas de login y menú.

Juan Carlos Alcazarde

Estadísticas y panel de administración.

Ignacio del Peso

Juego Tres en Raya y su vista.

1.6Guía de métodos por clase

A continuación se listan todos los métodos de cada clase con una descripción de su función.

MODELO

Usuario (abstracta)

Jugador extends Usuario

Administrador extends Usuario

Juego (abstracta)

TresEnRaya extends Juego

PasaPalabra extends Juego

Partida

PuntuacionJugador

Estadistica

CONTROLADORES

GestorUsuarios

GestorJuegos

GestorPartidas

GestorEstadisticas

PERSISTENCIA

GestorPersistencia (interfaz)

PersistenciaArchivos implements GestorPersistencia

VISTA

Aplicacion

Tema (final)

No tiene métodos. Declara únicamente constantes public static final. Colores: FONDO, FONDO_PANEL, FONDO_OSCURO, FONDO_CAMPO, FONDO_INPUT, ACENTO, TEXTO, SUBTEXTO, ERROR, BORDE, BORDE_INPUT, CORRECTO, INCORRECTO, PASAPALABRA, ACTUAL, PENDIENTE, FICHA_X, FICHA_O, GRIS_BOTON. Fuentes: FUENTE_TITULO, FUENTE_LABEL, FUENTE_CAMPO, FUENTE_BOTON, FUENTE_ENLACE, FUENTE_GRANDE, FUENTE_CELDA, FUENTE_TURNO, FUENTE_PUNTOS, FUENTE_TIEMPO, FUENTE_LETRA, FUENTE_DEFINICION, FUENTE_RESPUESTA, FUENTE_BOTON_JUEGO, FUENTE_ROSCO.

VentanaLogin extends JFrame

VentanaMenuPrincipal extends JFrame

VentanaSeleccionJuego extends JDialog

VentanaJuego (abstracta) extends JFrame

VentanaJuegoTresEnRaya extends VentanaJuego

VentanaJuegoPasapalabra extends JFrame (independiente)

VentanaEstadisticas extends JFrame

VentanaAdmin extends JFrame

PARTE 2 — ANÁLISIS TÉCNICO DEL CÓDIGO

Esta parte está basada en la lectura directa del código fuente ubicado en /JuegoFinal/Programa/src/.

2.1Estructura de paquetes

JuegoFinal/Programa/

├── src/

│   ├── Controlador/     GestorEstadisticas, GestorJuegos, GestorPartidas, GestorUsuarios

│   ├── Modelo/          Administrador, Estadistica, EstadoPartida (enum), Juego,

│   │                    Jugador, Partida, PasaPalabra, PuntuacionJugador,

│   │                    TresEnRaya, Usuario

│   ├── Persistencia/    GestorPersistencia (interfaz), PersistenciaArchivos

│   └── Vista/           Aplicacion, Tema, VentanaAdmin, VentanaEstadisticas,

│                        VentanaJuego, VentanaJuegoPasapalabra,

│                        VentanaJuegoTresEnRaya, VentanaLogin,

│                        VentanaMenuPrincipal, VentanaSeleccionJuego

└── data/

    ├── usuarios.txt          username;sha256hash;esAdmin

    ├── estadisticas.txt      username;juego;pts;victoria;fecha (generado en runtime)

    ├── partidas/id.dat       nombreJuego|users|estadoSerializado (generado en runtime)

    └── roscos/

        ├── rosco_infantil.txt    Letra;Definición;Respuesta  (269 líneas)

        ├── rosco_facil.txt

        ├── rosco_medio.txt

        └── rosco_avanzado.txt

2.2Paquete Modelo

Usuario (abstracta)

Propósito: clase base para todos los usuarios del sistema. Gestiona identidad y autenticación.

Relaciones: extendida por Jugador y Administrador. Usada por GestorUsuarios, GestorPartidas, Partida.

Jugador extends Usuario

Sin campos propios. toArchivo() serializa esAdmin siempre como false.

Relaciones: instanceof comprobado en GestorUsuarios.esAdministrador() y VentanaAdmin.

Administrador extends Usuario

Sin campos propios. toArchivo() serializa esAdmin como true.

Relaciones: instanceof comprobado en GestorUsuarios.esAdministrador() y VentanaAdmin. VentanaMenuPrincipal muestra el botón de admin solo si el usuario es instancia de esta clase.

Juego (abstracta)

Propósito: clase base de todos los juegos. Define estado compartido y el contrato abstracto de mecánica.

Relaciones: extendida por PasaPalabra y TresEnRaya. Agregada en Partida (campo juego). GestorPartidas trabaja siempre con referencia tipo Juego (polimorfismo).

TresEnRaya extends Juego

Propósito: implementación del juego Tres en Raya para dos jugadores.

Detalle de serialización: "casilla00,casilla01,...,casilla22;ganador" donde casillas vacías se representan como espacio y sin ganador como "null". VentanaJuegoTresEnRaya castea la referencia Juego de Partida a TresEnRaya para acceder a jugarTurno() y getTablero().

PasaPalabra extends Juego

Propósito: juego PasaPalabra con rosco de 27 letras y 4 niveles de dificultad.

Carga de roscos: cargarDatos() lee el fichero del nivel, divide en bloques de 10 preguntas por letra y elige una al azar en cada bloque. Esto garantiza variedad entre partidas. limpiarTexto() normaliza NFD y elimina diacríticos para comparar respuestas sin sensibilidad a tildes.

Partida

Propósito: sesión concreta de juego. Coordina turno circular, estado y resultados.

Estadistica

Propósito: registro inmutable del resultado de una partida para un jugador concreto.

PuntuacionJugador y EstadoPartida

PuntuacionJugador es un par (username, puntos) utilizado internamente por Juego. EstadoPartida es un enum con tres valores: EN_CURSO, PAUSADA y FINALIZADA.

2.3Paquete Controlador

GestorUsuarios

Gestiona autenticación, registro y sesión activa.

Relaciones: usa GestorPersistencia para cargar/guardar. VentanaLogin llama iniciarSesion() y registrarUsuario(). VentanaAdmin usa esAdministrador() y getListaUsuarios().

GestorJuegos

Registro de juegos disponibles y fábrica (Factory Method) para crear instancias.

Relaciones: Aplicacion.main() registra "TresEnRaya" y "Pasapalabra". VentanaMenuPrincipal y VentanaSeleccionJuego consultan getJuegosDisponibles(). crearJuego() instancia TresEnRaya o PasaPalabra según el nombre.

GestorPartidas

Gestiona el ciclo de vida completo de las partidas.

Formato del fichero .dat: "nombreJuego|user1,user2|estadoSerializado" (formato con jugadores). También soporta el legado "nombreJuego|estadoSerializado" (sin jugadores). Relaciones: delega persistencia en GestorPersistencia. VentanaMenuPrincipal y ventanas de juego llaman iniciarPartida(), pausarPartida(), finalizarPartida().

GestorEstadisticas

Registro y consulta de estadísticas históricas.

Los algoritmos de ordenación (calcularRanking, getUltimasPartidas) usan bubble sort implementado a mano con LocalDate.isBefore(). Relaciones: VentanaEstadisticas y VentanaAdmin consumen sus métodos. VentanaJuego y VentanaJuegoPasapalabra llaman registrarResultado() al finalizar.

2.4Paquete Persistencia

GestorPersistencia (interfaz)

Define 8 operaciones de acceso a datos agrupadas en tres áreas: usuarios (guardar/cargar), estadísticas (agregar/cargar) y partidas pausadas (guardar/cargar/eliminar/listar). La separación mediante interfaz permite cambiar PersistenciaArchivos por cualquier otra implementación (BD relacional, XML, red) sin afectar a los controladores.

PersistenciaArchivos implements GestorPersistencia

Implementación sobre ficheros de texto plano en la carpeta data/.

El constructor crea los directorios necesarios con mkdirs() si no existen. El formato de usuarios.txt es "username;sha256hash;esAdmin" (un usuario por línea). estadisticas.txt usa append (no se sobreescribe; cada partida añade una línea). Los ficheros .dat en data/partidas/ almacenan el estado serializado completo de una partida pausada.

2.5Paquete Vista

Aplicacion — Punto de entrada

main() crea PersistenciaArchivos, instancia los 4 gestores inyectando la persistencia, registra los dos juegos disponibles ("TresEnRaya" y "Pasapalabra") en GestorJuegos, y lanza VentanaLogin dentro de SwingUtilities.invokeLater() para garantizar que todo el código Swing corra en el Event Dispatch Thread. Expone los gestores como campos estáticos accesibles desde todas las ventanas.

VentanaLogin

Alterna entre modo login y modo registro con un único botón de cambio de modo. En modo registro: valida campos, crea el usuario, hace auto-login y abre el menú. Muestra mensajes de error en rojo (Tema.ERROR) en un JLabel dedicado.

VentanaMenuPrincipal

Hub central de la aplicación. Muestra botón de administración solo si el usuario tiene rol de Administrador. La acción "Jugar" inicia el flujo completo: selección de juego, opcionalmente solicitar credenciales del 2º jugador (si multijugador), crear partida, y abrir la ventana específica del juego.

La acción "Cargar Partida" obtiene la lista de partidas pausadas del usuario y muestra sus etiquetas legibles en un JOptionPane. Al seleccionar, reconstruye el objeto Juego correcto, llama reanudarPartida() y abre la ventana correspondiente.

VentanaJuegoTresEnRaya

Tablero de 9 JButton dispuestos en GridLayout 3×3. Cada botón llama manejarJugada(). La ficha asignada a cada jugador (X para el jugador 0, O para el jugador 1) se determina comparando el índice en listaJugadores con turnoActual. Cuando el juego termina, muestra JOptionPane con el resultado y llama a accionFinalizar() heredado de VentanaJuego.

VentanaJuegoPasapalabra

No extiende VentanaJuego. Incluye un Timer Swing que cuenta 150 segundos (2:30 min). El panel central es PanelRosco, una inner class que sobreescribe paintComponent() para dibujar 27 círculos en disposición circular, cada uno coloreado según el estado de su letra (verde=correcta, rojo=incorrecta, azul=pasapalabra, gris=pendiente, amarillo=actual). Al finalizar muestra un resumen HTML en un JOptionPane con aciertos, fallos, pasapalabras y puntuación.

VentanaEstadisticas

JTable con modelo DefaultTableModel y 4 columnas (Juego, Puntuación, Resultado, Fecha). Carga las estadísticas del usuario actual al construir.

VentanaAdmin

JTabbedPane con dos pestañas. "Ranking": JComboBox con los juegos disponibles; al cambiar el juego se recalcula y muestra el ranking. "Usuarios": tabla con todos los usuarios registrados y su tipo (ADMIN / Usuario).

Tema

Clase utilitaria final no instanciable. Centraliza la paleta de colores y el conjunto de fuentes de la aplicación. Todas las ventanas referencian Tema.FONDO, Tema.ACENTO, Tema.FUENTE_TITULO, etc. en lugar de valores hardcodeados.

2.6Flujo de ejecución — del arranque a una partida

1. Arranque

main() en Aplicacion crea PersistenciaArchivos y los 4 gestores (GestorUsuarios, GestorJuegos, GestorPartidas, GestorEstadisticas). GestorUsuarios y GestorEstadisticas cargan datos de disco. GestorPartidas sincroniza contadorId con los .dat existentes. GestorJuegos registra "TresEnRaya" y "Pasapalabra". SwingUtilities.invokeLater lanza VentanaLogin.

2. Login / Registro

El usuario introduce credenciales. Si es login, GestorUsuarios.iniciarSesion() verifica el hash. Si es registro, GestorUsuarios.registrarUsuario() valida formato, unicidad, crea Jugador, guarda en disco. En ambos casos, si OK, VentanaLogin abre VentanaMenuPrincipal y se oculta.

3. Selección de juego

El usuario pulsa "Jugar". VentanaMenuPrincipal abre VentanaSeleccionJuego (modal). El usuario elige el juego y pulsa "Jugar". Si es multijugador (TresEnRaya), se pide username y contraseña del 2º jugador con verificación de credenciales.

4. Inicio de partida

VentanaMenuPrincipal llama GestorJuegos.crearJuego() para obtener la instancia. Luego llama GestorPartidas.iniciarPartida(juego, jugadores), que invoca juego.inicializar() y crea la Partida con id autoincremental y estado EN_CURSO. A continuación abre VentanaJuegoTresEnRaya o VentanaJuegoPasapalabra según el juego.

5. Juego en curso — Tres en Raya

Cada clic en un botón del tablero llama manejarJugada(). manejarJugada() llama juego.jugarTurno(username, ficha, fila, columna). TresEnRaya coloca la ficha, comprueba victoria/empate y suma 10 pts si hay victoria. La ventana llama partida.siguienteTurno() y actualizarVista(). Si el juego terminó, mostrarResultado() llama accionFinalizar().

5. Juego en curso — Pasapalabra

El timer corre 150 s. El jugador teclea en txtRespuesta y pulsa "Responder" u "onPasapalabra". PasaPalabra.procesarRespuesta() normaliza y compara; si correcta suma 10 pts y avanza. pasarPalabra() marca PASAPALABRA y avanza circularmente. Cada acción llama actualizarVista() que repinta PanelRosco. Al llegar a 0 letras pendientes o al terminar el timer, se llama accionFinalizar().

6. Pausa (opcional)

El usuario pulsa "Pausar". La ventana llama GestorPartidas.pausarPartida(), que serializa el estado del juego como "nombreJuego|user1,user2|estadoSerializado" y lo persiste en data/partidas/id.dat. La ventana se cierra y vuelve a VentanaMenuPrincipal.

7. Reanudación

El usuario pulsa "Cargar Partida". GestorPartidas.listarPartidasUsuario() filtra los .dat que contienen el username. El usuario selecciona una partida. VentanaMenuPrincipal llama GestorJuegos.crearJuego(), GestorPartidas.reanudarPartida() (que parsea el .dat y llama juego.deserializarEstado()), y abre la ventana de juego.

8. Finalización

accionFinalizar() (o accionFinalizar() interno en Pasapalabra) llama primero GestorPartidas.finalizarPartida() (que marca la partida como FINALIZADA, la añade al historial y elimina el .dat), y luego GestorEstadisticas.registrarResultado(partida), que crea una Estadistica por jugador y la persiste en estadisticas.txt. La ventana se cierra y vuelve a VentanaMenuPrincipal.

2.7Mapa de conexiones entre clases

2.8Discrepancias entre diseño y código real

⚠ Las siguientes diferencias se encontraron al comparar la documentación de diseño inicial con el código fuente.

1. Jerarquía de usuarios

Diseño original: Usuario con boolean esAdmin. Código real: Usuario abstracta + subclases Jugador y Administrador. La diferencia es una mejora: permite polimorfismo con instanceof y facilita futuros roles sin modificar código existente.

2. VentanaJuegoPasapalabra no extiende VentanaJuego

Diseño: VentanaJuegoPasapalabra debería extender VentanaJuego (abstracta). Código real: extiende directamente JFrame. Motivo: la lógica de temporizador y resumen final de Pasapalabra difiere suficientemente de accionFinalizar() de VentanaJuego. Consecuencia: algo de código duplicado (pause/finalizar implementado de forma independiente).

3. GestorUsuarios no tiene clase GestorPersistencia propia

El diseño mencionaba "GestorPersistencia (colaboración con JP)" para Adrián Duque. En el código, GestorPersistencia es una interfaz única implementada por PersistenciaArchivos; no hay implementación separada por gestor.

4. Clase Tema no estaba en el diseño inicial

Añadida durante la implementación como buena práctica de centralización de estilos. No modifica ningún comportamiento funcional.

5. VentanaSeleccionJuego no estaba en el diseño inicial

Añadida como JDialog modal para el flujo de selección de juego. No estaba en la arquitectura original pero encaja limpiamente en la capa Vista.

6. Usuario usa nombre Jugador (no Usuario concreta)

El diseño mencionaba "Usuario" como posible clase concreta para jugadores normales. En el código se usa "Jugador" como subclase de Usuario (abstracta). Más correcto desde el punto de vista OO.

7. Bubble sort en GestorEstadisticas en lugar de Collections.sort()

Las ordenaciones en calcularRanking() y getUltimasPartidas() están implementadas con bubble sort manual. No es un error de diseño sino una decisión de implementación, posiblemente por familiaridad del autor con el algoritmo.

Conclusión

El proyecto implementa correctamente todos los requisitos del enunciado: dos juegos funcionales, gestión de usuarios con roles, persistencia en ficheros sin dependencias externas, arquitectura en cuatro capas con herencia polimorfismo e interfaces, historial de estadísticas, pausa/reanudación de partidas y panel de administración. Las discrepancias encontradas son mejoras respecto al diseño inicial, no regresiones.