marti/WarhammerQuest
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
WarhammerQuest/DEVLOG.md

18 KiB
Raw Permalink Blame History

Devlog - Warhammer Quest (Versión Web 3D)

Sesión 8: Sistema de Magia, Audio y Pulido UI (7 Enero 2026)

Objetivos Completados

  1. Sistema de Audio Inmersivo:

    • Implementada reproducción de efectos de sonido (SFX).
    • Pasos en bucle al mover entidades.
    • Sonidos de combate: Espadazos, flechas.
    • Sonido ambiental al abrir puertas.

  2. Sistema de Magia Avanzado (Bola de Fuego):

    • Implementada mecánica de selección de área de efecto (2x2).
    • Feedback Visual: Visualización de rango y línea de visión (Verde/Rojo) en tiempo real al apuntar.
    • Secuencia de Ataque Completa: Proyectil físico ➔ Impacto ➔ Explosión Central ➔ Daño en área.
    • Daño individual calculado para cada monstruo afectado.
    • Cancelación de hechizo mediante clic derecho.

  3. Feedback de Combate Unificado:

    • Centralizada la lógica de visualización de daño en showCombatFeedback.
    • Muestra claramente: Daño (Rojo + Temblor), Bloqueos (Amarillo), Fallos (Gris).
    • Aplicado tanto a magia como a ataques físicos.

  4. Mejoras de UI:

    • Las estadísticas de las cartas de personaje ahora usan abreviaturas en español claras (H.C, Fuer, Res, etc.) en lugar de siglas en inglés crípticas.

Estado Actual

El juego dispone de un sistema de combate rico visual y auditivamente. La magia se siente poderosa "gameplay-wise". La interfaz es más amigable para el usuario hispanohablante.

Tareas Pendientes / Known Issues

  1. Sincronización de Audio: Los SFX de pasos a veces continúan un instante tras acabar la animación.
  2. Animación Doble: Ocasionalmente se reproducen dos animaciones de ataque o feedback superpuestos.
  3. Interfaz de Hechizos: Actualmente lista todos los hechizos en botones; se necesitará un seleccionador tipo "Libro de Hechizos" cuando el Mago tenga más opciones.

Objetivos Completados

  1. Vista Táctica (Toggle 2D/3D):

    • Implementado botón en UI para alternar views.
    • 2D: Cámara cenital pura (Top-Down) para planificación táctica.
    • Visualización de Tokens:
      • En modo 2D, las miniaturas 3D se complementan con Tokens planos.
      • Imágenes Específicas: Carga dinámica de assets para héroes (heroes/barbarian.png...) y monstruos (enemies/orc.png...).
      • Sincronización: Los tokens se mueven en tiempo real y desaparecen limpiamente al volver a 3D.
    • UX: Transiciones suaves y gestión robusta de visibilidad.

  2. Refinamiento de Línea de Visión (LOS):

    • Implementado algoritmo estricto (Amanatides & Woo) para evitar tiros a través de muros.
    • Tolerancia de Rozamiento: Añadido margen (hitbox 0.4) para permitir tiros que rozan el borde de una casilla de entidad.
    • Corrección de "Diagonal Leaking": Solucionado el problema donde los disparos atravesaban esquinas diagonales entre muros (se verifican ambos vecinos en cruces de vértice).
    • Detección de Muros por Conectividad: Reemplazada la comprobación simple de vacío por canMoveBetween, asegurando que los muros entre habitaciones/pasillos contiguos bloquen la visión correctamente si no hay puerta, incluso si ambas celdas tienen suelo.

  3. Sistema de Audio:

    • Implementado SoundManager para gestión centralizada de audio.
    • Música Ambiental: Reproducción de Abandoned_Ruins.mp3 con loop y manejo de políticas de autoplay del navegador.
    • Efectos de Sonido (SFX): Gatillo de sonido opendoor.mp3 sincronizado con la apertura visual de puertas.

Estado Actual

El juego cuenta con una visualización táctica profesional y un sistema de línea de visión robusto y justo, eliminando los fallos de detección en esquinas y muros.

Próximos Pasos

  • Sistema de combate completo (dados, daño).
  • UI de estadísticas y gestión de inventario.

Sesión 6: Sistema de Fases y Lógica de Juego (5 Enero 2026)

Objetivos Completados

  1. Reglas de Juego Oficiales (WHQ 1995):

    • Se ha implementado un estricto control de fases: Exploración, Aventureros y Monstruos.
    • Exploración Realista: Colocar una loseta finaliza el turno inmediatamente.
    • Tensión en Nuevas Áreas: Al entrar en una nueva habitación, el héroe se detiene OBLIGATORIAMENTE (haya monstruos o no) y se revela el evento.
    • Combate Continuo: Si hay monstruos vivos, se elimina la Fase de Exploración del ciclo y se salta la Fase de Poder para mantener un bucle de combate frenético (Aventureros <-> Monstruos).

  2. Movimiento y Eventos:

    • Refinamiento de executeMovePath en GameEngine:
      • Detecta entrada en nuevos tiles.
      • Diferencia entre Habitaciones (Trigger Event + Stop) y Pasillos (Solo marcar visitado).
      • Detiene el movimiento sin penalizar los pasos no dados.

  3. Interacción de Héroes:

    • Implementado ataque básico haciendo clic izquierdo en monstruos adyacentes durante el turno propio.
    • Permitido movimiento en fases de Exploración para facilitar el posicionamiento táctico antes de abrir puertas.

  4. Monstruos e IA:

    • Los monstruos de habitación ya no sufren "mareo de invocación" y atacan en el turno siguiente a su aparición.
    • Ajustada la IA para operar correctamente dentro del nuevo flujo de fases.

Estado Actual

El núcleo del juego ("Game Loop") es funcional y fiel a las reglas de mesa. Se puede explorar, revelar salas, combatir y gestionar los turnos con las restricciones correctas.

Próximos Pasos

  • Implementar sistema completo de combate (tiradas de dados visibles, daño variable, muerte de héroes).
  • Refinar la interfaz de usuario para mostrar estadísticas en tiempo real.

Sesión 5: Refinamiento de UX y Jugabilidad (3 Enero 2026)

Objetivos Completados

  1. Validación Estricta de Puertas:

    • Implementado control riguroso para puertas multicelda.
    • Si una puerta tiene 2 celdas, la tile conectada DEBE tener 2 salidas alineadas.
    • Fix: selectDoor ahora recupera el objeto salida completo (con tileId) para poder validar correctamente el grupo de celdas.

  2. UX de Colocación:

    • Reemplazados alert() nativos con modales showModal() y showConfirm() estilizados.
    • Implementado botón de Descarte para bloquear puertas cuando una tile no cabe o no interesa.

  3. Sistema de Movimiento Táctico:

    • Planificación: Click en jugador para seleccionar → Clicks en celdas contiguas para trazar ruta (1, 2, 3...).
    • Deshacer: Click en el último paso para eliminarlo.
    • Ejecución: Click derecho para iniciar el movimiento.
    • Animación: Implementado efecto de "botecito" (salto sinusoidal) al mover entre casillas.
    • Visualización: Marcadores amarillos con números sobre las casillas planificadas.

  4. Aleatoriedad Visual:

    • Implementado sistema de Texturas Aleatorias para losetas con múltiples variantes (Rooms).
    • DungeonGenerator elige una textura al instanciar, GameRenderer la pinta.
    • Corrección de definición duplicada de room_objective en TileDefinitions.js (eliminada versión incorrecta de 4x4).

  5. Mejoras de Cámara:

    • Zoom Ajustado: Rango modificado a 3-15 (default 6) para una vista más lejana y cómoda.
    • Sincronización: El slider de zoom ahora se actualiza al usar la rueda del ratón.
    • Paneo: Se modificó la lógica de paneo para mover tanto la cámara como el objetivo (target), evitando el efecto de órbita indeseado. Estado final: Pendiente de validación por reporte de fallo en controles.

Estado Actual

El juego es completamente jugable en cuanto a exploración y movimiento. La generación de mazmorras es robusta y visualmente más variada gracias a las texturas aleatorias. La interfaz es consistente y amigable.

Próximos Pasos

  • Revisar controles de cámara (Paneo).
  • Implementar sistema de turnos / fases de juego.
  • Añadir enemigos y lógica de combate.

Sesión 4: Sistema de Colocación Manual - Estado Actual (2 Enero 2026)

Objetivo

Implementar un sistema de colocación manual de tiles donde el jugador:

  1. Mueve al bárbaro junto a una puerta
  2. Hace click en la puerta para abrir y revelar una nueva tile
  3. Puede rotar/mover la tile flotante antes de colocarla
  4. Confirma la colocación con el botón "Bajar"

Trabajo Realizado

1. Limpieza de Código

  • Problema: Código viejo de gameplay mezclado con nuevo sistema de construcción
  • Solución:
    • Copiado GameEngine.js y main.js a carpetas old/ con fecha (20260102)
    • Reescrito versiones minimalistas enfocadas SOLO en construcción manual
    • Añadido sistema de jugador (bárbaro) con movimiento básico

2. Flujo de Trabajo Implementado

  • ✅ Bárbaro aparece en primera tile
  • ✅ Click en bárbaro → selección (anillo amarillo)
  • ✅ Click en celda → movimiento
  • ✅ Click en puerta adyacente → abre y muestra tile flotante
  • ✅ Tile flotante a Y=3 con proyección verde/roja en suelo
  • ✅ Panel de controles (rotar, mover, bajar)

3. Problemas Identificados y Parcialmente Resueltos

Problema 1: Dimensiones de Tiles

  • Error: Usaba .length en lugar de .height para dimensiones de variantes
  • Impacto: Rooms aparecían como 1x4 en lugar de 4x4
  • Solución: Cambiado a usar variants.N.width y variants.N.height

Problema 2: Rotación de Texturas

  • Error: Aplicaba rotación visual a planos con dimensiones ya rotadas
  • Intento de solución: Usar dimensiones BASE (NORTH) y aplicar rotación Z
  • Estado: Implementado pero no verificado completamente

Problema 3: Posicionamiento Decimal

  • Error: Coordenadas de placement eran decimales (1.5, 2.5)
  • Solución: Añadido Math.round() en selectDoor para anchor inicial

Estado Actual - PROBLEMAS CRÍTICOS

🔴 TILES NO SE COLOCAN CORRECTAMENTE

  • Las dimensiones siguen siendo incorrectas para algunos tiles
  • La rotación visual no coincide con la proyección lógica
  • Las tiles se mueven de posición al bajarlas (T-junction)
  • Rooms aparecen deformadas o mal dimensionadas

Causa Raíz del Problema

Confusión entre dos conceptos:

  1. Dimensiones lógicas (celdas que ocupa la tile) - calculadas desde cells
  2. Dimensiones visuales (tamaño del plano 3D) - deberían ser de la textura

El problema fundamental:

  • Las texturas están diseñadas para orientación NORTH
  • Cuando roto una tile, las CELDAS cambian de posición
  • Pero la TEXTURA sigue siendo la misma imagen
  • Estoy mezclando dimensiones de celdas rotadas con texturas sin rotar

Archivos Modificados

  • src/engine/game/GameEngine.js - Reescrito (versión limpia)
  • src/main.js - Reescrito (versión limpia)
  • src/view/GameRenderer.js - Múltiples cambios en addTile y showPlacementPreview
  • src/engine/dungeon/DungeonGenerator.js - Añadido redondeo de coordenadas

Próximos Pasos Recomendados

  1. PAUSA: Reiniciar ordenador, aumentar RAM
  2. REVISIÓN COMPLETA: Analizar la lógica de dimensiones vs rotación desde cero
  3. SIMPLIFICACIÓN: Quizás necesitamos un enfoque completamente diferente para el renderizado de tiles rotadas

Sesión 3b: Corrección Crítica de Alineación (2 Enero 2026)

Diagnóstico del "Desastre"

Tras refactorizar el generador, las piezas aparecían desalineadas o superpuestas.

  • Causa Raíz: Inconsistencia de Sistemas de Coordenadas.
  • Detalle:
    • Los nuevos Corridors usaban definiciones de salida "Pre-Rotadas" (coordenadas relativas al ancla después de rotar).
    • Las Habitaciones y Uniones (Rooms/Junctions) usaban definiciones "Locales" (coordenadas relativas al tile sin rotar).
    • El nuevo DungeonGenerator asumía que TODAS las definiciones eran "Pre-Rotadas" y sumaba las coordenadas directamente.
    • Esto causaba que Rooms y Junctions rotados hacia el Este/Sur/Oeste se calcularan en posiciones totalmente erróneas (fuera del tile).

Solución Implementada

Se unificó todo el sistema al paradigma Pre-Rotated Relative Offsets:

  1. Actualización Masiva: Se reescribieron las definiciones exitsByRotation para corridor_corner, junction_t, room_dungeon y room_objective.
  2. Lógica Geométrica:
    • NORTH: X positivo, Y positivo.
    • EAST: X positivo, Y negativo (el tile crece hacia abajo).
    • SOUTH: X negativo, Y negativo (el tile crece hacia izquierda/abajo).
    • WEST: X negativo, Y positivo (el tile crece hacia izquierda/arriba).
  3. Verificación: Ahora todas las definiciones de salida coinciden con la geometría real generada por GridSystem en cada rotación.

Estado

  • ✅ Alineación: Debería ser perfecta para todos los tipos de tiles y rotaciones.
  • ✅ Código: Mucho más limpio y sin cálculos trigonométricos en tiempo de ejecución.

Sesión 3: Refinamiento de Generación de Mazmorras (2 Enero 2026)

Resumen General

Sesión enfocada en resolver problemas fundamentales de alineación de tiles en la generación de mazmorras. Se identificó que el problema raíz estaba en el uso de cálculos dinámicos de rotación para tiles con definiciones estáticas de salidas.

Trabajo Realizado

1. Análisis del Problema de Rotación

  • Descubrimiento clave: Las definiciones de tiles en TileDefinitions.js tienen salidas con coordenadas y direcciones estáticas (relativas a orientación Norte).
  • Problema: Los cálculos de getRotatedOffset() y getRotatedDirection() asumían tiles cuadrados y simétricos, fallando con tiles asimétricos (corridors 2x6, L-corners con forma irregular).
  • Impacto: Corridors y L-corners se colocaban desalineados, creando gaps entre tiles.

2. Implementación de Configuraciones de Corridor

  • Contexto del manual: Los corridors tienen 1 puerta fija y 1 puerta variable con 3 posiciones posibles (Norte, Este lateral, Oeste lateral).
  • Solución inicial: Creamos exitConfigurations para corridors con 3 opciones de salida.
  • Decisión: Corridors NO rotan, solo cambian de configuración de salida.
  • Resultado: Simplifica la lógica pero no resuelve el problema de otros tiles.

3. Enfoque de Salidas Explícitas por Rotación

  • Decisión de diseño: Cambiar de cálculos dinámicos a definiciones explícitas.
  • Implementación: Añadir exitsByRotation a cada tile que rota (L-Corner, T-Junction, Rooms).
  • Estructura: 
    exitsByRotation: {
    [DIRECTIONS.NORTH]: [ /* exits for North orientation */ ],
    [DIRECTIONS.EAST]: [ /* exits for East orientation */ ],
    [DIRECTIONS.SOUTH]: [ /* exits for South orientation */ ],
    [DIRECTIONS.WEST]: [ /* exits for West orientation */ ]
}

4. Tiles Actualizados

  • ✅ L-Corner (corridor_corner): 4 rotaciones definidas explícitamente
  • ✅ T-Junction (junction_t): 4 rotaciones definidas explícitamente
  • ✅ Dungeon Room (room_dungeon): 4 rotaciones definidas explícitamente
  • ✅ Objective Room (room_objective): 4 rotaciones definidas explícitamente
  • ✅ Corridors: Mantienen exitConfigurations (3 opciones, sin rotación)

Estado Actual

Completado

  • ✅ Definiciones de exitsByRotation para todos los tiles que rotan
  • ✅ Definiciones de exitConfigurations para corridors
  • ✅ Logs de diagnóstico mejorados para debugging

En Progreso

  • ⚠️ DungeonGenerator.js: Lógica de step() parcialmente actualizada
    • Se añadió detección de exitsByRotation
    • PROBLEMA: Errores de sintaxis en bucles anidados (11 errores de linting)
    • Necesita reestructuración completa de la lógica de iteración

Pendiente

  • ❌ Eliminar cálculos de rotación obsoletos (getRotatedOffset, getRotatedDirection) una vez que exitsByRotation funcione
  • ❌ Pruebas completas de alineación con las nuevas definiciones
  • ❌ Limpieza de código y eliminación de logs de debug

Problemas Identificados

  1. Bucles anidados incorrectos: La lógica actual tiene 3 niveles de bucles mal estructurados:

    • Configuraciones (para corridors)
    • Rotaciones (para otros tiles)
    • Salidas (para cada rotación/configuración)

  2. Mezcla de enfoques: El código intenta manejar simultáneamente:

    • exitConfigurations (corridors sin rotación)
    • exitsByRotation (otros tiles con rotación)
    • Cálculos dinámicos (legacy, debe eliminarse)

Próximos Pasos (Mañana)

Prioridad Alta

  1. Reestructurar step() en DungeonGenerator.js:

    • Separar lógica para corridors (exitConfigurations) vs otros tiles (exitsByRotation)
    • Simplificar bucles anidados
    • Eliminar cálculos de rotación cuando se use exitsByRotation

  2. Verificar alineación:

    • Probar cada tipo de tile en todas sus rotaciones
    • Confirmar que no hay gaps ni overlaps

Prioridad Media

  1. Limpieza de código:

    • Eliminar getRotatedOffset() y getRotatedDirection() (obsoletos)
    • Remover logs de debug innecesarios
    • Documentar la nueva estructura

  2. Optimización:

    • Revisar performance de la generación
    • Considerar caché de configuraciones válidas

Notas Técnicas

Ventajas del enfoque exitsByRotation:

  • ✅ Elimina errores de cálculo matemático
  • ✅ Funciona para cualquier forma de tile (simétrico o asimétrico)
  • ✅ Fácil de verificar manualmente
  • ✅ Sin ambigüedad en las conexiones

Desventajas:

  • ❌ Más código (cada tile requiere 4 definiciones)
  • ❌ Propenso a errores manuales al escribir coordenadas
  • ❌ Más difícil de mantener si cambian dimensiones de tiles

Decisiones de Diseño

  1. Corridors no rotan: Solo cambian configuración de puerta (3 opciones)
  2. Otros tiles rotan: Usan exitsByRotation con 4 orientaciones explícitas
  3. Sin cálculos dinámicos: Las salidas ya están en coordenadas correctas para cada rotación
  4. Logs detallados: Mantener durante debugging, eliminar en producción

Sesión 2: Refinamiento de Generación (31 Diciembre 2025)

Resumen

Implementación de sistema de exploración guiada por jugador y mejoras en la interfaz de usuario.

Hitos Alcanzados

  • ✅ Sistema de movimiento de jugador implementado
  • ✅ Selección de puertas para exploración
  • ✅ Modal de confirmación para abrir puertas
  • ✅ Generación paso a paso según decisiones del jugador
  • ✅ Cámara con transiciones suaves entre vistas
  • ✅ Mejoras en UI (botones, controles, feedback visual)

Sesión 1: Inicialización y Motor 3D (30 Diciembre 2025)

Resumen

Establecimiento de la base completa del motor de juego con generación procedimental y visualización 3D.

Hitos Alcanzados

  • ✅ Infraestructura dockerizada (Nginx + Node.js/Vite)
  • ✅ Motor de juego (GridSystem, DungeonGenerator, DungeonDeck)
  • ✅ Visualización 3D con Three.js
  • ✅ Sistema de cámara isométrica
  • ✅ Carga de texturas y assets