WarhammerQuest/DEVLOG.md

Sesión 18: Refinado de Spawning y Ajustes de Corredores

Fecha: 11 de Enero de 2026

Objetivos

• Corregir el spawn de monstruos en eventos de fase de poder (Minotauro).
• Ajustar la generación de salidas en la loseta inicial.
• Mejorar la visualización de notificaciones y la lógica de daño grupal.

Cambios Realizados

1. Spawn Hero-Centric para Eventos

• Restricción de Área: Modificada la lógica de findSpawnPoints en GameEngine.js para que los monstruos generados por Eventos de Poder solo aparezcan en losetas ocupadas por héroes, evitando que aparezcan en el vacío o en zonas inexploradas.
• Fix Spawn Inicial: Corregido bug de spawn inicial de héroes que causaba que aparecieran fuera de los límites (coordenada 0,0) si no se detectaban posiciones válidas inicialmente.

2. Ajuste de Salidas Iniciales

• Regla del Inicio: Los pasillos colocados como loseta inicial (tile_0) ahora habilitan exactamente 2 salidas aleatorias (en lugar de 1 o 4), ofreciendo opciones estratégicas equilibradas desde el comienzo.
• Continuidad: El resto de pasillos mantienen la regla de 1 salida extra para mantener la estructura de la mazmorra.

3. Mejoras en EventInterpreter

• Daño Grupal: Implementada "herencia de objetivos" en EventInterpreter.js. Si un efecto afecta a "todos", ahora se aplica correctamente a todos los héroes seleccionados en la acción previa.
• Logs Descriptivos: Refinados los mensajes de log de eventos para ser más descriptivos: ahora detallan quién activó la trampa y a quién afecta exactamente el daño.

4. UX/UI y Estética

• Posicionamiento de UI: Desplazada la posición de los mensajes de notificación temporales (cartel rojo) a la zona inferior (70% de altura) para evitar solapamientos críticos con los botones de acción (Acabar Turno, etc.).
• Actualización de Assets: Vinculadas nuevas texturas específicas para las salas de laboratorio y la bóveda en TileDefinitions.js (room_4x4_skull.png, room_4x4_clean.png).

---

Sesión 17: Reglas de Mazmorra y Control de Pasillos

Fecha: 11 de Enero de 2026

Objetivos

• Cumplir estrictamente con la composición del mazo de mazmorra (18 cartas originales).
• Implementar la mecánica de barajado de 13 cartas con el objetivo en la mitad inferior.
• Limitar el número de salidas en los pasillos para evitar laberintos infinitos.
• Establecer una regla de proximidad (4 celdas) para la generación de nuevas puertas.

Cambios Realizados

1. Fiel Composición del Mazo (Warhammer Quest 1995)

• Mazo de 18 Cartas: El pool inicial ahora contiene exactamente 6 salas de subterráneo, 7 pasillos, 3 cruces en T, 1 esquina y 1 escalera.
• Estructura de 13 Cartas: Al generar la misión, se crea un mazo de 13 cartas:
  • 6 cartas aleatorias arriba.
  • 1 sala de objetivo + 6 cartas aleatorias barajadas abajo.
• Salas Específicas: Se han definido 6 variantes de salas de subterráneo y 5 salas de objetivo únicas (room_objective_1 a 5) en TileDefinitions.js.
• Assets de Backup: Generadas texturas placeholder (room_4x4_placeholder.png, room_4x8_placeholder.png) para las nuevas salas para asegurar la carga visual.

2. Control de Salidas en Pasillos (Regla de las 2 Salidas)

• Limitación de Ramificación: Los pasillos, que lógicamente tienen 4 direcciones, ahora solo habilitan un máximo de 2 salidas (la entrada utilizada + una salida extra aleatoria).
• Control de Proximidad Táctico:
  • Antes de habilitar una salida extra en un pasillo, el sistema verifica que la celda de salida esté a una distancia mínima de 4 celdas de cualquier otra habitación (ROOM u OBJECTIVE_ROOM).
  • Si una salida potencial está demasiado cerca de una estructura existente, se descarta para evitar colisiones visuales y mecánicas.
• Visualización: Durante la fase de "Placing Tile", el jugador sigue viendo todas las salidas en azul, pero al confirmar, el sistema activa solo las permitidas.

Tareas Pendientes / TODO

• [Avanzado] Implementar conectividad automática: si una pieza recién colocada queda adyacente a una pared con puerta de otra habitación, permitir la conexión física entre ambas.

---

Sesión 16: Reglas de Exploración y Refinado de Eventos

Fecha: 11 de Enero de 2026

Objetivos

• Ajustar la progresión de la fase de exploración según el manual original (1995).
• Refinar el evento de "Derrumbamiento" para permitir una huida táctica.
• Restaurar la aleatoriedad total en los mazos de juego (Eventos y Mazmorra).

Cambios Realizados

1. Exploración Diferida

• Revelación en Fase de Héroes: Ahora los héroes pueden entrar en estancias nuevas durante su fase. La habitación se marca como "visitada", pero no se genera el encuentro inmediatamente.
• Resolución en Fase de Monstruos: La carta de evento se roba al inicio de la Fase de Monstruos, antes de que estos actúen.
• Movimiento Completo: Los aventureros pueden completar todo su movimiento al entrar en una sala nueva (no se bloquean en la primera casilla), pero su turno termina al llegar a su destino.
• Finalización Manual: Se ha eliminado el salto automático de turno al entrar en una sala, permitiendo al jugador gestionar el orden de sus héroes manualmente antes de pasar al siguiente.

2. Refinado del "Derrumbamiento" (Collapse)

• Margen de Huida: Se ha ajustado el contador de colapso a 2 turnos para dar tiempo real a los héroes a salir de la estancia.
• Exención de Pinning: Siguiendo el reglamento, los héroes no pueden ser trabados en combate mientras la habitación se derrumba (pueden huir ignorando a los monstruos).
• Zonas Intransitables: Una vez colapsada, la estancia se marca físicamente como bloqueada en la cuadrícula, impidiendo cualquier re-entrada.

3. Restauración de Aleatoriedad

• Mazo de Eventos: Eliminados los "cheats" de desarrollo que forzaban el Enano y el Rastrillo. Ahora el mazo es 100% aleatorio.
• Mazo de Mazmorra: Reintroducidas todas las secciones especiales (esquinas, cruces en T, escaleras). La composición del mazo vuelve a ser equilibrada y variada.

4. Correcciones y Mejoras Técnicas

• Fix tile_0: La habitación inicial se marca como explorada por defecto para evitar disparos de eventos fantasmas al inicio.
• Corregida lógica de nombres: Se ha arreglado un error donde el nombre de la carta robada no se mostraba correctamente en los logs.
• Restaurada GridSystem: Corregido un error que impedía colocar tiles tras la última actualización.

---

Sesión 15: Evento del Rastrillo, Llave del Enano e Inventario

Fecha: 10 de Enero de 2026

Objetivos

• Implementar el evento del "Rastrillo" (bloqueo de entrada por portcullis).
• Crear un sistema de inventario funcional para todos los héroes.
• Vincular la adquisición de la "Llave del Rastrillo" con la capacidad de abrir la puerta bloqueada.

Cambios Realizados

1. Sistema de Inventario

• Propiedad Universal: Se ha añadido un array inventory a nivel de objeto para todos los héroes en su inicialización.
• Interfaz Visual (InventoryUI.js): Nueva interfaz estilo "mochila" que muestra los items recolectados por cada héroe.
• Integración en UI: Habilitado el botón "🎒 INVENTARIO" en las fichas de unidad para desplegar el contenido de la mochila.
• Gestión de Items: El EventInterpreter ahora soporta la acción EFECTO (tipo: item), permitiendo que los eventos entreguen objetos físicos a los aventureros.

2. Evento del Rastrillo (Portcullis)

• Bloqueo Inteligente: El GameEngine ahora rastrea la última entrada utilizada (lastEntranceUsed).
• Nuevas Acciones de Entorno: Implementado el subtipo bloquear_entrada_rastrillo en EventInterpreter.
• Detección de Llave: Al intentar abrir una puerta bloqueada por un rastrillo, el juego verifica si algún héroe del grupo posee la llave_rastrillo.
• Textura de Rastrillo: Se añadió soporte para door1_portcullis.png en DungeonRenderer.js.
• Safeguards de Renderizado: Se añadieron protecciones en el renderizador de puertas para evitar que la animación de "abrir puerta" sobreescriba visualmente el estado de "puerta bloqueada" o "portcullis".

Estado Actual

El sistema de inventario y la lógica de la llave funcionan correctamente. El evento del Enano Moribundo entrega la llave al grupo, y esta permite levantar el rastrillo. Pendiente: Se ha detectado un problema visual donde la textura de door1_portcullis.png no parece aplicarse correctamente en algunos casos, a pesar de que la lógica de bloqueo funciona. Se requiere una revisión más profunda del sistema de materiales de Three.js para este caso.

---

Sesión 14: Estabilización del Flujo de Juego y Bugfix Crítico

Fecha: 10 de Enero de 2026

Objetivos

• Solucionar el bloqueo crítico al revelar nuevas estancias ("Estancia Revelada - Preparando encuentro...").
• Refinar el sistema híbrido de notificaciones (Log persistente + Texto flotante).

Cambios Realizados

1. Corrección del Bloqueo en "Estancia Revelada"

• Síntoma: Al entrar en una habitación nueva, el juego mostraba el mensaje de "Preparando encuentro..." pero se quedaba congelado en la fase de Héroes, impidiendo que los monstruos o el evento se activaran.
• Causa: La lógica de eventos difería la resolución a la Fase de Monstruos (pendingExploration), pero el cambio de fase no se disparaba automáticamente si no había enemigos previos, dejando al juego en un estado indeterminado ("limbo").
• Solución:
  • Se ha modificado GameEngine.js para resolver el evento de exploración inmediatamente al entrar en la sala (callback en executeMovePath).
  • Si surgen monstruos, se fuerza el cambio a Fase de Monstruos.
  • Si la sala está despejada, se mantiene la Fase de Héroes, permitiendo continuar el turno.
• Mejora en EventInterpreter: Se añadió soporte para callbacks de finalización (onComplete), permitiendo un control de flujo más granular en lugar de depender ciegamente de resumeFromEvent.

2. Sistema de Notificaciones Híbrido

• Consola Persistente: Se ha refinado el panel de log en la esquina inferior izquierda (FeedbackUI.js) para mantener un historial de eventos de combate y reglas.
• Texto Flotante: Se mantiene renderer.showFloatingText para feedback inmediato y efímero sobre las unidades (daño, estados).
• Integración: GameEngine ahora redirigide los mensajes de eventos críticos a ambos sistemas según su importancia.

Estado Actual

El juego es ahora estable en el ciclo principal de exploración y combate. La transición entre descubrir una sala y combatir monstruos es fluida e inmediata, sin pausas extrañas ni bloqueos.

---

Sesión 13: Eventos de Exploración y Regla de Derrumbamiento

Fecha: 9 de Enero de 2026

Objetivos

• Implementar la mecánica de "Derrumbamiento" (Collapse) con todas sus reglas asociadas.
• Establecer el sistema de Eventos de Exploración al entrar en nuevas estancias ("Room Revealed").

Cambios Realizados

1. Mecánica de Derrumbamiento ("Collapse")

• Regla de "Sala Inicial": Si se roba la carta de Derrumbamiento en la sala de inicio (tile_0) o en el turno 1, se ignora y se roba otra carta automáticamente para evitar un "Game Over" inmediato antes de empezar.
• Bloqueo Visual de Salidas: Implementada la función collapseExits que:
  • Identifica las salidas no abiertas de la sala actual.
  • Coloca marcadores visuales de "Escombros" y cambia la textura de las puertas a "Bloqueada".
  • Elimina lógicamente las salidas del generador de mazmorras.
  • Agrupa celdas de puerta adyacentes para reportar un conteo de puertas "humanas" (visuales) en lugar de celdas individuales en el log.
• Cuenta Atrás Mortal: Implementado estado de collapsingRoom. Al final del siguiente turno, cualquier entidad (héroe o monstruo) que permanezca en la sala muere aplastada instantáneamente.
• Destrabarse Gratis: Modificada la lógica attemptBreakAway. Si la sala se está derrumbando, los héroes ignoran las zonas de control de los monstruos y escapan automáticamente (éxito garantizado) para intentar salvar su vida.

2. Eventos de Exploración (Nuevas Estancias)

• Detección de Entrada: El sistema de movimiento (executeMovePath) ahora detecta si el héroe entra en una celda de tipo ROOM que no ha sido visited.
• Interrupción de Movimiento: Al entrar en una habitación nueva, el héroe se detiene instantáneamente y pierde el resto de su movimiento ("Stop").
• Fase de Monstruos: Al inicio de la Fase de Monstruos, si hay una exploración pendiente:
  • Se roba una carta del Mazo de Eventos.
  • Si es un Evento, se resuelve normalmente.
  • Si son Monstruos, se generan DENTRO de la sala recién revelada (gracias a la inyección de contexto tileId en findSpawnPoints).

Estado Actual

El juego ahora soporta situaciones de crisis extremas (Derrumbes) y la tensión natural de abrir puertas desconocidas. La exploración ya no es segura; cada nueva sala es una amenaza potencial que se activa en el turno de los monstruos.

Sesión 12 (Continuación): Refactorización y Renderizado (Intento II - Exitoso)

Fecha: 9 de Enero de 2026

Objetivos

• Completar la refactorización de GameRenderer.js sin las regresiones visuales del primer intento.
• Solucionar el error crítico de inicialización de módulos (setPathGroup is not a function).

Cambios Realizados (Refactor V2 "Quirúrgica")

• Modularización Exitosa:
  • SceneManager.js: Gestiona escena, cámara y luces. Se incluyó el fix de window.innerHeight para evitar la pantalla negra.
  • DungeonRenderer.js: Renderizado de tiles, puertas y Niebla de Guerra. Mantiene filtros NearestFilter y SRGBColorSpace.
  • EntityRenderer.js: Renderizado de héroes, monstruos y animaciones. Mantiene la lógica de limpieza de ruta paso a paso.
  • InteractionRenderer.js: Mantiene la visualización exacta de rutas (cuadrados amarillos con números) y gestión de input.
  • EffectsRenderer.js: Partículas y textos flotantes.
  • GameRenderer.js: Actúa como fachada (Facade) delegando llamadas a los módulos.

Corrección de Errores (Hotfix)

• Error: Uncaught TypeError: this.entityRenderer.setPathGroup is not a function.
• Causa: El navegador mantenía una versión caché de EntityRenderer.js anterior a la implementación del método setPathGroup.
• Solución:
  1. Se añadió un log de inicialización en el constructor de EntityRenderer (V2.1) para forzar la actualización del módulo.
  2. Se envolvió la llamada a setPathGroup en GameRenderer con una validación de tipo (typeof ... === 'function') y un log de error explícito para evitar el crash de la aplicación.

Estado Actual

• El juego carga correctamente.
• La estructura de código está modularizada y limpia.
• No hay regresiones visuales: Los héroes se ven nítidos (pixel art) y la visualización de movimiento es la original.

---

Sesión 12: Refactorización y Renderizado (Intento I)

Fecha: 9 de Enero de 2026

Objetivos

• Refactorizar visualmente el GameRenderer.js para dividirlo en submódulos ordenados (Dungeon, Entity, Effect, Interaction).
• Mejorar la escalabilidad del código de renderizado y separar responsabilidades.

Ocurrido

• Se realizó un intento completo de refactorización que, aunque arquitectónicamente sólido, introdujo regresiones visuales críticas:
  • Pantalla Negra: Debido a una inicialización del canvas basada en un contenedor de altura 0, corregida con window.innerHeight.
  • Pérdida de Estilo Píxel: Las miniaturas de los héroes se veían borrosas/blanquecinas por olvidar THREE.SRGBColorSpace y minFilter/magFilter: Nearest.
  • Cambio de Estilo: La visualización de rutas de movimiento era diferente a la original.

Acción Táctica

• Reversión (Rollback): Se decidió revertir todos los cambios de renderizado (git restore) para volver a un estado visualmente perfecto y comenzar la refactorización (v2) de forma segura y controlada, aplicando las lecciones aprendidas (altura del canvas, filtros de textura) desde el principio.

Próximos Pasos (Inmediato)

• Re-implementar la refactorización de GameRenderer de forma "Quirúrgica", copiando la lógica visual original línea por línea para no alterar la estética pixel-art ni el comportamiento del juego.

---

Sesión 11: Sistema de Iniciativa y Niebla de Guerra (Fog of War)

Fecha: 9 de Enero de 2026

Objetivos

• Implementar el sistema de Niebla de Guerra (Fog of War) basado en la regla de la Lámpara: Visibilidad limitada a la sección actual y adyacentes.
• Establecer un sistema de turnos estricto basado en Iniciativa para la fase de Aventureros.

Cambios Realizados

1. Sistema de Iniciativa y Turnos

• Orden de Turno: Implementada la lógica initializeTurnOrder en GameEngine.
  • El Portador de la Lámpara (Líder) siempre actúa primero.
  • El resto de héroes se ordenan por su atributo de Iniciativa (Descendente).
• Control Estricto:
  • Modificado onCellClick para impedir la selección y control de héroes que no sean el activo durante la Fase de Aventureros.
  • Se visualiza el héroe activo mediante un Anillo Verde (vs Amarillo de selección).
• Ciclo de Turnos: Métodos activateNextHero y nextHeroTurn para avanzar ordenadamente.

2. Niebla de Guerra (Lamp Rule)

• Lógica de Adyacencia de Secciones:
  • Se abandonó la idea de radio por celdas simples.
  • Nueva lógica: Se identifica la Sección de Tablero (Tile) del Líder.
  • Se calculan las secciones conectadas físicamente (puertas/pasillos) mediante análisis de canMoveBetween en la rejilla.
• Renderizado Dinámico de Niebla:
  • GameRenderer ahora agrupa las losetas en dungeonGroup.
  • Método updateFogOfWar que oculta/muestra losetas y Entidades (héroes/monstruos) basándose en la visibilidad de su posición.
  • La iluminación se actualiza en tiempo real con cada paso del portador de la lámpara.

3. UX de Combate

• Feedback Visual de Objetivo: Se ha añadido un Anillo Azul que señala al héroe objetivo de un monstruo antes de que se realice el ataque, permitiendo al jugador identificar la amenaza inmediatamente.
• Limpieza de UI: Al comenzar la fase de monstruos, se eliminan automáticamente todos los indicadores de selección (anillos verdes/amarillos) para limpiar la escena.
• Persistencia de Héroe Activo: El héroe activo ya no pierde su estado de selección al moverse o al hacer clic sobre sí mismo accidentalmente, mejorando la fluidez del turno.

4. UX y Lógica de Juego

• Ocultación de Entidades en Niebla: Los héroes y monstruos que quedan fuera del alcance de la lámpara (losetas no visibles) ahora desaparecen completamente de la vista, aumentando la inmersión.
• Salto de Turno Automático: Si un héroe comienza su turno en una zona oscura (oculta por la Niebla de Guerra), pierde automáticamente su turno hasta que sea "rescatado" (iluminado de nuevo) por el Portador de la Lámpara.
• Botones de Fase: Se ha reorganizado la barra superior. El botón de "Acabar Fase" ahora comparte espacio con un nuevo botón "Acabar Turno" específico para cada héroe, facilitando el flujo de juego sin tener que buscar en la ficha del personaje.
• Sistema de Destrabado (Break Away): Implementada la mecánica para escapar del combate cuerpo a cuerpo ("Trabado").
  • Los héroes trabados verán un botón de "Destrabarse" en su ficha.
  • Al pulsarlo, el sistema lanza 1D6 contra el valor pin_target del héroe.
  • Éxito: El héroe recupera su libertad de movimiento. Fallo: El héroe pierde su movimiento y debe luchar.

Estado Actual

El juego ahora respeta las reglas de visión y turno del juego de mesa original con una fidelidad visual alta. La sensación de exploración es más tensa al ocultarse las zonas lejanas ("se perderán en la oscuridad"), y el orden táctico es crucial. La UI es más intuitiva y limpia durante el combate.

---

Sesión 10: Refactorización Arquitectónica de UI

Fecha: 8 de Enero de 2026

Objetivos

• Reducir la complejidad del UIManager.js (que superaba las 1500 líneas).
• Modularizar la interfaz para facilitar el mantenimiento y la escalabilidad.
• Separar responsabilidades claras entre HUD, Cartas de Unidad, Feedback, etc.

Cambios Realizados

1. Modularización de UIManager

Se ha dividido el monolito UIManager.js en 6 componentes especializados ubicados en src/view/ui/:

• HUDManager.js:
  • Gestiona elementos estáticos de pantalla (Minimapa, Controles de Cámara, Zoom).
  • Mantiene el bucle de renderizado del minimapa 2D.
• UnitCardManager.js:
  • Controla el panel lateral izquierdo con las fichas de Héroes y Monstruos.
  • Maneja los botones de acción contextual (Atacar, Disparar, Inventario).
• TurnStatusUI.js:
  • Panel superior central. Muestra Fase actual, Turno y botón de "Fin de Fase".
  • Visualiza los resultados de la Fase de Poder.
• PlacementUI.js:
  • Interfaz específica para la colocación de losetas (flechas de control, rotar, confirmar/cancelar).
• FeedbackUI.js:
  • Sistema centralizado de comunicación con el usuario.
  • Gestiona Modales, Ventanas de Confirmación y Mensajes Flotantes.
  • Implementa el Log de Combate (anteriormente notificación simple).
• SpellbookUI.js:
  • Módulo independiente para el libro de hechizos visual del Mago.

2. UIManager como Orquestador

El archivo principal UIManager.js se ha reducido drásticamente (~140 líneas). Ahora actúa únicamente como "pegamento":

• Inicializa los subsistemas.
• Escucha eventos del GameEngine (selección de entidades, cambio de fase).
• Delega la actualización de la interfaz a los módulos correspondientes.

Estado Actual

La refactorización es totalmente transparente para el usuario final (la funcionalidad visual se mantiene idéntica), pero el código es ahora robusto, mantenible y listo para crecer sin convertirse en código espagueti.

Próximos Pasos

• Implementar la Gestión de Inventario real.
• Pulir efectos visuales de hechizos y combate.

---

Sesión 9: Pulido de Combate, UI de Hechizos y Buffs

Fecha: 8 de Enero de 2026

Objetivos

• Resolver la duplicación de animaciones en el ataque de los monstruos.
• Mejorar la interfaz de usuario para el manejo de hechizos (Libro de Hechizos Visual).
• Implementar validaciones de línea de visión (LOS) en el lanzamiento de hechizos.
• Añadir nuevos hechizos ("Piel de Hierro") y sistema de duración de efectos (Buffs).

Cambios Realizados

1. Corrección de Animaciones y Audio

• Doble Animación: Se eliminó la llamada redundante a onEntityHit dentro de MonsterAI.js. Ahora el feedback visual (destello rojo/temblor) se delega exclusivamente a game.onCombatResult, unificando el flujo entre héroes y monstruos y evitando que la animación se dispare dos veces.
• Audio: Se investigó el retraso en el audio del golpe. Se decidió mantener el sonido actual (sword1.mp3) por el momento.

2. Interfaz de Usuario (UI)

• Botón de Inventario: Añadido un botón placeholder "🎒 INVENTARIO" a las fichas de todos los aventureros.
• Libro de Hechizos (Mago):
  • Se reemplazó la lista de botones de texto por un sistema visual de cartas.
  • Al hacer clic en "HECHIZOS", se despliega una mano de cartas generadas dinámicamente con plantillas (attack_template, defense_template, healing_template).
  • Las cartas muestran el coste de poder en la esquina y se oscurecen si no hay maná suficiente.
  • Implementado cierre automático al seleccionar o hacer clic fuera.

3. Sistema de Magia y Buffs

• Validación LOS: Corregido bug donde "Bola de Fuego" podía lanzarse a través de muros aunque la previsualización mostrara rojo. Ahora onCellClick valida estrictamente la línea de visión antes de ejecutar.
• Nuevo Hechizo: Piel de Hierro:
  • Coste: 5. Tipo: Defensa.
  • Efecto: Otorga +2 a Resistencia durante 1 turno.
  • Requiere selección de objetivo (héroe).
• Sistema de Buffs Temporales:
  • Implementado evento turn_ended en TurnManager.
  • Añadido método handleEndTurn en GameEngine para gestionar la duración de los efectos.
  • Los buffs ahora se limpian automáticamente cuando su duración llega a 0, revirtiendo los cambios en las estadísticas.

Estado Actual

El combate se siente mucho más sólido sin las animaciones dobles. La interfaz del mago es ahora visualmente atractiva y funcional. El sistema de magia soporta hechizos de defensa y buffs con duración limitada, abriendo la puerta a mecánicas más complejas.

Próximos Pasos

• Implementar la funcionalidad real del Inventario.
• Añadir más cartas/hechizos y refinar el diseño visual de los textos en las cartas.
• Ajustar el timing del sonido de ataque para sincronizarlo perfectamente con la animación de impacto.

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

3. Limpieza de código:

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

4. 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