yovi_es2b

Frontend Web: Permitir a las personas jugar partidas del juego Y a través del navegador.

Versión Clásica: Implementar el juego contra la máquina con un tamaño de tablero variable, esto se definirá con "Dificultad" o "Tamaño" según se juegue contra un bot o un jugador local respectivamente.

Estrategias de BOT: El juego contra la computadora debe implementar más de una estrategia seleccionable que seguirá el bot contra el que se juegue. En nuestro caso, se han implementado 6: Random, Ofensiva, Defensiva y estrategia que usa el algoritmo de MonteCarlo, que tiene 3 variaciones que aumenta la dificultad.

Niveles de Dificultad: El jugador podrá elegir el nivel de dificultad de las estrategias. Como lo mencionado antes, esto inidica el tamaño de los tableros exclusivamente al jugar contra un bot.

Despliegue: La aplicación deberá estar desplegada y ser accesible de forma pública en la Web. Podemos seguir el siguiente enlace: http://gameyes2b.duckdns.org/.

Gestión de Usuarios: Registro en el sistema y consulta de histórico. Esto significa que se pueden crear usuarios, para registrar las estadísticas y guardarlas, para poder verlas y hacer un ranking de todos los usuarios.

API Documentada: Se refiere a una interfaz que permite que los bots con las estrategias para que puedan interactuar con el juego y la gestión de usuarios y partidas.

Modo Bot: El API expondrá un método play con notación YEN para que un bot ajeno a nosotros juegue contra la aplicación.

Proporcionar una experiencia de juego fluida y coherente, garantizando que cada acción del jugador se valide correctamente y se refleje en el estado del tablero de forma inmediata.

Fomentar enfrentamientos amistosos con partidas multijugador (2 jugadores) y con un ranking de usuarios a partir de la puntuación obtenida.

Contribuir al entretenimiento y al desarrollo estratégico por las reglas del juego, fácil de entender gracias a la interfaz.

El frontend web: Desarrollado en React, hace que la aplicación se pueda ejecutar en el navegador. También se encarga de la presentación visual del juego, es decir, de la interfaz; la gestión de interacciones de los jugadores y la comunicación con el backend.

El backend: Se divide en tres microservicios independientes que gestionan distintas responsabilidades del sistema. El microservicio de GameY, en Rust, que tiene por función el manejo del juego como tal, los turnos del juego, los bots y sus estrategias, etc. El microservicio de usuarios, en Node.js, que resultará más sencillo para la comunicación con la base de datos. Por último, el microservicio de Rooms, también en Node.js, que gestiona las salas de juego multijugador en tiempo real mediante WebSocket (Socket.io), coordinando la creación y unión de salas y retransmitiendo los movimientos entre jugadores a través de GameY.

La persistencia de datos: Se realiza mediante MongoDB, que almacena la información de los usuarios con sus partidas y resultados. Elegimos el modelo noSQL por la facilidad de despliegue y la capacidad de ver los datos en tiempo real.

La comunicación entre frontend y backend: Se realiza mediante mensajes JSON siguiendo la notación YEN. Esta notación permite representar de manera precisa la situación de cada partida en un instante dado, facilitando tanto la interacción con la interfaz web como la integración con bots a través del API.

El sistema se despliega en un entorno contenerizado: Mediante Docker, lo que asegura reproducibilidad y consistencia en el entorno de ejecución. La aplicación se ejecuta en una máquina virtual en la nube, proporcionando disponibilidad remota y facilitando el acceso para usuarios y pruebas.

React: Para el frontend, una de las principales bibliotecas de JavaScript para construir interfaces de usuario. Permite la representación del tablero con componentes independientes.

Rust: Para el backend, lenguaje de programación que garantiza rendimiento y seguridad.

Node.js: Entorno de ejecución de JS caracterizado por su rendimiento y seguridad que será usado para el juego.

MongoDB: Base de datos no relacional. Más intuitiva y sencilla de montar en el servidor, además de estar orientada a JSON, que facilita la implementación.

Docker: Para el despliegue del sistema.

AWS: Aplicación donde se alojará una máquina virtual para la disponibilidad remota.

CSS: Lenguaje de programación en el que se definirán los estilos y el aspecto de la interfaz en un documento.

GitHub: Servicio web en la nube donde se subirán las distintas versiones, cambios, reuniones, decisiones, … en torno a la aplicación.

Gatling: Software que se usará para las pruebas de carga del juego.

Prometheus: Sistema de monitorización y alertas que recopila métricas de los microservicios en intervalos regulares.

Grafana: Plataforma de visualización que conecta con Prometheus para mostrar las métricas del sistema en dashboards en tiempo real.

Rendimiento: Se espera principalmente minimizar tiempos de respuesta de para que la experiencia de juego resulte fluida y con interrupciones mínimas tras cada movimiento, por lo que se buscara que el sistema procese los movimientos de forma prácticamente inmediata desde la perspectiva del usuario, evitando retrasos que puedan romper la dinámica del turno. No será necesario el acceso constante a la base de datos, lo que reducirá la latencia.

Consistencia y fiabilidad: El objetivo principal es garantizar que el estado del tablero sea siempre único, coherente y compartido entre ambos jugadores, impidiendo movimientos ilegales y asegurando el cumplimiento de las reglas. Evitando inconsistencias en el backend, se espera también como objetivo de calidad que el jugador no pueda alterar el estado del juego fuera de su turno, que también será consistente.

Mantenibilidad: Se busca que el sistema pueda modificarse sin afectar profundamente a varias partes del código. Ya sea por incluir nuevas características o cambiar las ya existentes, los cambios deben poder implementarse de manera controlada y localizada, estando el juego adaptado y con una clara separación entre backend y frontend. También es importante el bajo acoplamiento y la gran cohesión para alcanzar este objetivo, así como la documentación.

Usabilidad: Tratando que los jugadores entiendan completamente el juego con su interfaz, se buscará evitar la sobrecarga cognitiva y se priorizará retroalimentación, representación clara del turno o el movimiento hecho y un tablero simple pero comprensible. La interfaz del juego será clara, intuitiva y familiar para el usuario para conseguir esto.

Robustez y seguridad: El objetivo es que el sistema resista comportamientos inesperados o intentos de manipulación. Se espera evitar que el jugador pueda alterar directamente el tablero o que los puntos ganados sean inconsistentes. Además, el juego debe ser capaz de gestionar situaciones como desconexiones, intentos de jugadas inválidas, …

Frontend web

Microservicio User

Microservicio GameY

Microservicio Rooms

Base de datos

Prioritaria: tareas imprescindibles para que el sistema funcione y sea evaluable, como la solución de errores de código central o aquellas partes necesarias para el desarrollo del trabajo de otros miembros del equipo o para el funcionamiento básico de la app. Esto incluye lógica principal del juego, la comunicación entre servicios, el registro de usuarios y la navegación básica de la interfaz.

Alta: mejoras que aumentan la calidad del producto, como la validación más estricta, los errores personalizados, la incorporación de las estadísticas y el ranking, …​ También estarían

Media: implementación de todos los test y documentación completa, además de extras de implementación como la opción de multijugador

Baja: ajustes de acabado, refactorizaciones, mejoras visuales y utilidades adicionales que no bloquean el desarrollo del núcleo. Además, apartados optativos como internacionalización u otros modelos visuales

Separación de responsabilidades: cada módulo, componente o servicio tiene un propósito concreto.

Bajo acoplamiento: los distintos servicios se comunican mediante interfaces simples, lo que facilita cambiar una parte sin romper las demás.

Alta cohesión: cada bloque de código agrupa comportamiento relacionado.

Código entendible: todas las partes del código han de ser entendidas por todos los miembros del equipo, independientemente de si han participado en su programación o no.

Arquitectura por capas: interfaz (webapp), lógica de aplicación (gameY) y acceso a datos quedan separadas (users).

Componente reutilizable: en el frontend, la mayor parte de la interfaz se construye a partir de componentes pequeños y combinables.

Controlador/servicio: en los servicios web, los controladores reciben peticiones y delegan el trabajo en servicios más específicos.

La lógica principal se mantiene lo más aislada e independiente posible de la interfaz gráfica.

Las llamadas a red y a base de datos se concentran en funciones concretas, fáciles de reproducir en pruebas.

Las validaciones importantes se realizan en puntos bien definidos, por lo que pueden verificarse con casos de entrada controlados.

La interfaz expone elementos identificables y estados visibles, lo que facilita comprobar el comportamiento desde pruebas automáticas.

El cliente no debe decidir el resultado de una partida ni alterar directamente el estado interno.

El servidor valida las acciones relevantes antes de aceptarlas.

Las entradas recibidas por red se tratan como no confiables hasta comprobar su formato y contenido.

Se evita exponer información sensible en respuestas, logs o mensajes de error innecesarios.

React: para construir la interfaz del webapp con componentes reutilizables.

Vite: para el arranque y empaquetado del frontend.

Vitest y Testing Library: para pruebas automáticas de componentes y pantallas.

Node.js: para el servicio de usuarios (microservicio users) y utilidades auxiliares del entorno web.

Rust: para la lógica principal del juego, priorizando rendimiento y seguridad.

Docker: para facilitar ejecución y despliegue en entornos homogéneos.

OpenAPI: para documentar los contratos de los servicios.

Prometheus: para la recopilación de métricas de los microservicios mediante scraping periódico.

Grafana: para la visualización de métricas en dashboards provisionados automáticamente.

Documentación: el uso de arc42 para explicar las decisiones y trazar los escenarios.

Nomenclatura consistente: se procura mantener nombres comprensibles y homogéneos entre módulos, e incluso a la hora de subir nuestras partes a GitHub.

Mantenibilidad visual: la interfaz intenta reutilizar patrones de diseño comunes para que nuevas pantallas se integren sin esfuerzo: buscamos de nuevo la simplicidad en una interfaz intuitiva y familiar.

Posibilidad para crecimiento: la estructura del proyecto permite añadir nuevas pantallas, modos de juego o métricas sin rehacer la base, y nos permite añadir los aspectos extra del proyecto.

Detectabilidad de fallos: la separación entre servicios y la personalización de errores facilita localizar errores y analizar fallos por capas.

Observabilidad: la integración de Prometheus y Grafana permite detectar anomalías de rendimiento y comportamiento sin necesidad de intervención manual sobre los servidores.

Funcionalidad (obligatoria): El sistema realiza las funciones obligatorias de creación de usuario e inicio de sesión con otro ya creado. También es posible jugar contra varios bot, que pueden tener diferentes estrategias y se puede ajustar la dificultad, que corresponde con el tamaño del tablero sobre el que se va a jugar. Existe la posibilidad de visualizar estadísticas personales de partidas contra bot: en general, por dificultad o por estrategia. Escenarios Funcionalidad del 1 al 3.

Mantenibilidad: Para modificaciones de funcionalidades voluntarias, necesitamos que nuestro programa pueda adaptarse sin tener que tocar el resto de código. Así, al poder crear implementaciones extra, no tendremos que sacrificar el rendimiento del programa o tiempo empleado en hacerlo, entre otras cosas.

Usabilidad: Debe poder ser usada para el público objetivo, que en nuestro caso, será apto para todos los públicos. Tendrá que tener una interfaz intuitiva y fácil de usar, con un rendimiento de la aplicación (creación de usuario, jugar un turno, etc.) que sea lo más rápido y correcto posible.

Escalabilidad: Este programa será capaz de funcionar en varios dispositivos al mismo tiempo. De esta forma, en un futuro, podría tener la capacidad de ser usado con mayor carga, pero sin perder rendimiento o calidad.

Funcionalidad (extra): Existe la capacidad de jugar un jugador contra otro, tanto de forma local, en el mismo ordenador, como de forma remota, con diferentes cuentas. También está la capacidad de poder ver un ranking global, con todos los usuarios registrados. Se ha implementado la capacidad de obtener pistas al jugar un usuario contra un bot, teniendo un límite de 3 pistas por patida. También se proporciona un temporizador en las partidas jugador vs jugador, si no se responde en ese tiempo, se cambiará el turno. Otra implementación es poder aplicar el modo oscuro, pudiendo elegir si usar la aplicación con modo claro (que en principio se había forzado) o en modo oscuro, este apartado está muy relacionado también con la usabilidad. Respecto a la usabilidad, de nuevo, se ha implementado la internacionalización, centrado en idiomas con letras latinas (español, inglés, …​). Escenarios Funcionalidad del 4 al 7.

Rendimiento: Este programa deberá responder a las peticiones de forma rápida y clara. La rapidez se corresponde con un sistema productivo, y la claridad con el como responde la aplicación y se muestra en el interfaz de usuario.

Testeabilidad: Corresponde con la capacidad de que cada parte de la aplicación tenga funcionalidades que pueden ser probadas. Estas pruebas se hacen mediante diferentes tipos de test: los unitarios, que hay uno por microservicio, sobre juego (gamey), sobre el interfaz (webapp) o sobre la base de datos (users); otros test son los test e2e, que prueban el flujo de una aplicación de principio a fin (e2e), que simulan la experiencia real de un usuario, probando que todos los componentes (frontend, backend, base de datos) funcionen conjuntamente; también tenemos las pruebas de carga, que muestran la capacidad del sistema para probar el acceso a la aplicación a la vez para simular una carga de trabajo más similar a la realidad; por último, tenemos las pruebas de usabilidad, que se hacen respecto a usuarios reales para ver su interacción con el juego.

WebApp-HomeScreen.test: Prueba que la pantalla inicial de bienvenida sea la adecuada y tenga el testo que esperamos, mostrando un panel para jugar contra la máquina y otro para jugar contra otro usuario. Además, se asegura que todos los botones funcionen según lo esperado, navegando, seleccionando o mostrando mensaje de error cuando sea necesario.

WebApp-Appheader.test: Prueba que el encabezado de la aplicación se renderice correctamente (logo y botón de menú), que el menú desplegable se abra y cierre como corresponde, que las opciones internas respondan bien (tema, cierre de sesión) y que el header no aparezca en pantallas donde no debe mostrarse.

WebApp-Board.test: Prueba la lógica visual y de interacción del tablero, validando carga inicial, número de celdas según dificultad, bloqueos de interacción, gestión de turnos y actualización del estado del juego tras realizar movimientos.

WebApp-GameScreen.test: Prueba que la pantalla del juego responda como es debido, mostrando la información de la partida, representado correctamente cuando este elije una casilla, navegando como se espera si el usuario decide terminar la partida, …​

WebApp-GameInfo.test: Prueba que la zona de información de partida (estado, mensajes y datos auxiliares) refleje correctamente el contexto del juego y se actualice cuando cambian las propiedades recibidas.

WebApp-EndGameScreen.test: Prueba que la pantalla final, la que sale cuando se gana o se pierde el juego (sin pulsar al botón terminar) aparezca con la información adecuada y correspondiente a la partida, además de que los botones de navegación funcionen correctamente.

WebApp-InitialScreen.test: Prueba que la pantalla para iniciar sesión tenga la información adecuada, responda correctamente a los datos que introduce el usuario y navegue como se espera a la pantalla de registro o a la de inicio/bienvenida

WebApp-SignUpScreen.test: Prueba que la pantalla registrar un nuevo usuario cuente que la información y textos esperados, responda de forma correcta a los datos que introduce el usuario y navegue como se espera que haga a otras pantallas.

WebApp-StatsScreen.test: Prueba que las pantallas de las estadísticas representen los datos como deberían, tanto para el caso de las estadísticas normales como para las filtradas, y que la navegación entre páginas se de según lo esperado.

WebApp-RankingScreen.test: Prueba que las pantallas de ranking muestran la información de la manera esperada en el caso de el ranking personal y de los rankings filtrados, respetando los estilos y el correcto funcionamiento de cada botón para la representación de los datos y para la navegación.

WebApp-Timer.test: Prueba el componente de temporizador, comprobando la representación del tiempo y su actualización en función del estado de la partida y del paso del tiempo.

WebApp-Theme.test: Prueba el contexto de tema (claro/oscuro), su alternancia y la persistencia de preferencias para asegurar un comportamiento consistente en toda la interfaz.

core_tests.rs — Tests del núcleo del juego: prueban directamente la lógica principal a través de la API pública de la librería. Cubren la inicialización del tablero, el flujo de movimientos y alternancia de turnos, las condiciones de victoria (conectar los tres lados), el manejo de errores como celdas ocupadas o turno incorrecto, las acciones especiales de resignación y swap, la serialización y deserialización en notación YEN, el guardado y carga de partidas en ficheros .yen, el sistema de coordenadas tridimensionales y el renderizado del tablero en texto.

bot_unit_tests.rs — Tests unitarios de los bots: verifican el comportamiento de cada estrategia de bot de forma aislada. Para cada bot disponible se comprueba que su nombre es el esperado, que devuelve un movimiento válido cuando hay celdas libres, que las coordenadas elegidas corresponden a una celda existente, y que devuelve None cuando el tablero está completo.

game_service_tests.rs — Tests de la capa de servicio: prueban el ciclo de vida de las partidas en memoria. Incluyen el flujo básico de crear, mover, listar, deshacer y eliminar una partida, la consulta del estado tras una resignación, y el manejo de errores como partida no encontrada, celda ocupada o deshacer sin historial suficiente.

game_controller_tests.rs — Tests de los controladores HTTP: prueban los endpoints REST del servidor Axum usando un router de test sin necesidad de levantar un servidor real. Verifican el flujo completo: creación de partida, listado, consulta de estado, realización de movimiento, deshacer y eliminación.

bot_server_tests.rs — Tests de integración del servidor de bots: prueban el servidor HTTP dedicado al cálculo de movimientos, comprobando los endpoints disponibles, el manejo de parámetros de posición codificados en la URL y la correcta devolución de movimientos.

cli_tests.rs — Tests de la interfaz de línea de comandos: prueban el parsing de comandos de la CLI del motor de juego, verificando que índices válidos, índices fuera de rango, comandos especiales y entradas desconocidas producen el resultado correcto.

register-logout-login.feature — Registro, cierre de sesión e inicio de sesión: valida el flujo básico de autenticación de un usuario nuevo de principio a fin. Un usuario se registra con credenciales nuevas, comprueba que llega a la pantalla principal, cierra sesión, vuelve a la pantalla de inicio de sesión e inicia sesión con las mismas credenciales, verificando que regresa a la pantalla principal.

logout-stats.feature — Cierre de sesión desde las pantallas de estadísticas: verifica que el botón de cierre de sesión funciona correctamente desde cualquiera de las pantallas de estadísticas. Cubre tres escenarios: cierre desde el menú principal de estadísticas, desde la pantalla de todas las estadísticas y desde la pantalla de estadísticas filtradas. En los tres casos se verifica que el usuario es redirigido a la página de inicio de sesión.

password-errors.feature — Validación de contraseña en el registro: comprueba que el formulario de registro muestra el mensaje de error correcto cuando la contraseña no cumple los requisitos. Utiliza un Scenario Outline con una tabla de ejemplos para cubrir los cuatro casos de validación: