Gestor de Torneos de Juegos de Mesa

Integrantes

BENJAMIN ALEJANDRO BRAVO PINTO
MARTIN GONZALO MUÑOZ LAPUENTE
GUSTAVO ERNESTO QUEVEDO SALGADO
YHOSER BRAULIO VILLEGAS POMA

Descripción del problema

Muchos torneos de juegos de mesa se organizan de forma manual, con lápiz y papel, lo que dificulta el registro de los jugadores, la generación de los enfrentamientos y el seguimiento de los resultados ronda a ronda. Este proyecto desarrolla una aplicación de escritorio que administra torneos por eliminación de distintos juegos de mesa: inscribe participantes, genera automáticamente los emparejamientos (bracket), registra el ganador de cada partida y determina al campeón, mostrando en todo momento el estado de la clasificación. Se ofrecen dos formatos: eliminación simple y doble eliminación.

Análisis del problema

Entidades participantes

Jugador: participante inscrito; guarda nombre, alias y su historial de victorias y derrotas.
Torneo: entidad central y abstracta; gestiona a los jugadores y las rondas. Se concreta en dos formatos: Eliminatorio Simple y Doble Eliminación.
Ronda: conjunto de partidas que se juegan en una misma fase del torneo.
Partida: enfrentamiento entre dos jugadores; tiene un estado y un ganador.
Administrador (actor externo): persona que opera la aplicación (crea el torneo, inscribe jugadores y registra los resultados).

Definición del sistema

El sistema es una aplicación de escritorio (C++17 + Qt) que mantiene en memoria el estado completo del torneo. A partir de la lista de jugadores genera las rondas y sus partidas, aplica las reglas del formato elegido para decidir quién avanza y calcula el campeón. La lógica del dominio (torneo, rondas, partidas, jugadores) está separada de la interfaz gráfica, que solo presenta ese estado y captura las acciones del administrador.

Interacción con el entorno

Entradas: el administrador crea el torneo (nombre, juego y formato), inscribe jugadores (nombre y alias) y selecciona el ganador de cada partida mediante cuadros de diálogo.
Procesamiento: el sistema baraja a los jugadores, arma el bracket, avanza de ronda cuando todas las partidas están resueltas y actualiza la clasificación de forma automática.
Salidas: visualización del bracket, la tabla de jugadores con su estado (inscrito, en competición, eliminado o campeón) y la exportación de los resultados a un archivo de texto.

Requerimientos — Casos de uso

Se documentan tres casos de uso principales con la plantilla estándar (nombre, propósito, actores, pre-condiciones, evento, curso normal en dos columnas Actor/Sistema, curso alternativo y requerimientos no funcionales). Los tres se emplean además como pruebas de verificación (ver Pruebas).

CU 1 · Crear e iniciar un torneo

Nombre Crear e iniciar un torneo

Propósito Configurar un torneo (nombre, juego y formato) e iniciarlo generando el bracket de la primera ronda.

Actores Administrador.

Pre-condiciones La aplicación está abierta. Para iniciar, deben existir al menos 2 jugadores inscritos.

Evento El administrador quiere comenzar un nuevo torneo.

Curso normal de eventos

Actor	Sistema
1. Selecciona «Nuevo torneo».
	2. Muestra el diálogo con nombre, juego y formato (eliminación simple o doble).
3. Indica los datos y confirma.
	4. Crea el torneo del formato elegido mediante `TorneoFactory` (Factory Method).
5. Inscribe a los participantes (CU 1) y pulsa «Iniciar».
	6. Verifica el mínimo de jugadores, los baraja, genera la ronda inicial con sus partidas y muestra el bracket; el torneo pasa a «En curso».

Curso alternativo 3a. Si falta el nombre o el juego, el sistema no crea el torneo y avisa.
6a. Si hay menos de 2 jugadores, el sistema muestra un aviso y no inicia el torneo.

Requerimientos no funcionales Los emparejamientos se generan de forma aleatoria. El sistema debe admitir un número de jugadores que no sea potencia de 2, asignando partidas BYE (pase directo) cuando corresponda.

CU 2 · Inscribir jugador

Nombre Inscribir jugador

Propósito Registrar un nuevo participante en el torneo con su nombre y alias.

Actores Administrador.

Pre-condiciones Existe un torneo creado y en estado Configuración (aún no iniciado).

Evento El administrador decide agregar un jugador al torneo.

Curso normal de eventos

Actor	Sistema
1. Selecciona «Agregar jugador».
	2. Muestra el diálogo de inscripción.
3. Ingresa el nombre y el alias, y confirma.
	4. Valida los datos (el nombre es obligatorio).
	5. Crea el `Jugador`, lo agrega al torneo y lo muestra en la tabla como «Inscrito».

Curso alternativo 4a. Si el nombre está vacío, el sistema muestra un aviso y no inscribe al jugador.
1a. Si el torneo ya está en curso, la opción de agregar jugadores está deshabilitada.

Requerimientos no funcionales La inscripción y el refresco de la tabla deben ser inmediatos (< 1 s). La validación ocurre antes de modificar el modelo, evitando estados inconsistentes.

CU 3 · Registrar el resultado de una partida

Nombre Registrar el resultado de una partida

Propósito Registrar al ganador de una partida, actualizar la clasificación y avanzar el torneo hasta el campeón.

Actores Administrador.

Pre-condiciones El torneo está En curso y la partida seleccionada está pendiente (no finalizada ni BYE).

Evento El administrador hace clic sobre una partida del bracket.

Curso normal de eventos

Actor	Sistema
1. Hace clic en una partida pendiente del bracket.
	2. Pregunta quién ganó (jugador 1 vs jugador 2).
3. Selecciona al ganador.
	4. Registra la victoria/derrota, marca la partida como `FINALIZADA` y actualiza la tabla.
5. Cuando la ronda está completa, pulsa «Avanzar ronda».
	6. Genera la siguiente ronda o, si queda un solo jugador, declara al campeón y finaliza el torneo.

Curso alternativo 2a. Si la partida ya está finalizada o es BYE, el sistema la ignora.
5a. Si la ronda no está completa, el sistema avisa que faltan resultados por registrar.

Requerimientos no funcionales La clasificación se actualiza automática e inmediatamente tras cada resultado. El estado del modelo y el de la vista se mantienen siempre consistentes.

Diseño

Diagrama de clases — capa de dominio

Modelo orientado a objetos del núcleo lógico. Torneo es el centro: agrega Jugador, se compone de Ronda y estas de Partida. El formato concreto se instancia con TorneoFactory y el flujo del torneo se define en la clase abstracta Torneo.

Diagrama de clases — capa de interfaz (Qt)

La interfaz orquesta el dominio pero no contiene la lógica del torneo: MainWindow posee el Torneo y cada widget recibe un puntero a él para refrescar su vista.

Diagrama de clases del dominio — Figura 1. Diagrama de clases.

Diagrama de secuencia

Caso de uso seleccionado: CU 3 — Registrar el resultado de una partida. Muestra el flujo desde el clic del administrador en el bracket hasta la actualización de los marcadores del jugador y el repintado de la vista.

Implementación

El sistema se implementó en C++17 con Qt Widgets, siguiendo una arquitectura por capas que separa el dominio de la interfaz:

Dominio: Jugador, Partida, Ronda, Torneo (abstracta) y sus formatos TorneoEliminatorioSimple y TorneoDobleEliminacion.
Patrones de diseño: Template Method en Torneo para el flujo común del torneo y Factory Method en TorneoFactory para crear el formato adecuado sin acoplar a la interfaz.
Gestión de memoria: los jugadores se comparten entre partidas mediante std::shared_ptr y el torneo se posee con std::unique_ptr, evitando fugas y punteros colgantes.
Interfaz y eventos: ventanas y diálogos de Qt conectados por el mecanismo de señales y slots; el bracket se dibuja con paintEvent() personalizado y emite la señal partidaSeleccionada() al hacer clic.

Pruebas

Prueba 1 · Creación e inicio de torneo (CU 2)

Se crea un torneo (nombre, juego y formato), se incorporan los participantes y se pulsa «Iniciar». La prueba comprueba que se exige un mínimo de 2 jugadores y que, al iniciar, se genera y muestra el bracket de la primera ronda.

Prueba 2 · Inscripción de jugador (CU 1)

Se inscribe un jugador indicando nombre y alias. La prueba verifica la validación del nombre obligatorio y que el jugador queda registrado y visible en la tabla de participantes con estado «Inscrito».

Prueba 3 · Registro de resultado y avance (CU 3)

Se hace clic en una partida, se selecciona al ganador y se comprueba que el marcador del jugador se actualiza (victoria/derrota), la partida queda finalizada y, al completar la ronda, el sistema avanza hasta anunciar al campeón.

Dificultades encontradas y cómo se superaron

Número de jugadores que no es potencia de 2: generaba emparejamientos incompletos. Se introdujo el estado BYE en Partida para dar pase automático a la siguiente ronda.
Propiedad de la memoria: un mismo jugador aparece en varias partidas. Se solucionó compartiéndolo con std::shared_ptr en lugar de punteros crudos.
Sincronización interfaz–modelo: tras cada acción la vista podía quedar desactualizada. Se centralizó el refresco en actualizarUI(), invocado después de cada operación.
Dibujo del bracket: posicionar partidas y conectores. Se implementó un paintEvent() propio en WidgetBracket.

Bugs y limitaciones conocidas

No se detectaron errores críticos durante las pruebas de los casos de uso.
El estado del torneo vive en memoria: no hay persistencia en disco entre ejecuciones (sí se pueden exportar los resultados a una planilla excel).
Los emparejamientos iniciales son aleatorios y no configurables (no admite sembrado manual).
Mejora futura sugerida: persistencia mediante base de datos y siembra de jugadores por ranking.

Código fuente

Puede descargar el proyecto completo (código fuente, README.md y archivo de proyecto TorneoMesa.pro para compilar con qmake) desde el siguiente enlace:

⬇ Descargar código fuente del proyecto

Compilación: qmake TorneoMesa.pro && make. El paquete incluye únicamente código fuente (carpetas include/, src/, ui/); no contiene binarios ni archivos del IDE.