Fix tile rendering dimensions and alignment, update tile definitions to use height
This commit is contained in:
279
DEVLOG.md
279
DEVLOG.md
@@ -1,55 +1,242 @@
|
||||
# Devlog - Sesión 1: Inicialización y Motor 3D
|
||||
# Devlog - Warhammer Quest (Versión Web 3D)
|
||||
|
||||
## Fecha: 30 de Diciembre, 2025
|
||||
## 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
|
||||
En esta sesión se ha establecido la base completa del motor de juego para **Warhammer Quest (Versión Web 3D)**. Se ha pasado de un concepto inicial a una aplicación dockerizada con generación procedimental de mazmorras y visualización isométrica en 3D.
|
||||
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**:
|
||||
```javascript
|
||||
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)
|
||||
|
||||
#### 1. Infraestructura
|
||||
* **Dockerización**: Se creó un entorno conteinerizado usando `Dockerfile` y `docker-compose`. La aplicación corre sobre **Nginx** (Frontend) y se construye con **Node.js/Vite**.
|
||||
* **Estructura del Proyecto**: Configuración de `package.json`, `index.html` limpio, y carpetas organizadas (`src/engine`, `src/view`, `public/assets`).
|
||||
---
|
||||
|
||||
#### 2. Motor de Juego (Engine)
|
||||
* **GridSystem**: Implementación de un sistema de coordenadas global y local. Soporte para rotación de baldosas y detección de colisiones mediante matrices de ocupación (`layout`).
|
||||
* **DungeonGenerator**: Lógica central de generación.
|
||||
* Gestiona el bucle de "Paso a paso" (Step).
|
||||
* Conecta baldosas basándose en las salidas (`Exits`) disponibles.
|
||||
* Valida superposiciones antes de colocar una pieza.
|
||||
* **DungeonDeck (Reglas)**: Implementación fiel al libro de reglas.
|
||||
* Mazo de 13 cartas.
|
||||
* Mezcla inicial de cartas de mazmorra y pasillo.
|
||||
* Inserción de la "Habitación Objetivo" en la segunda mitad (últimas 7 cartas) para asegurar una duración de partida adecuada.
|
||||
* **TileDefinitions**: Base de datos de baldosas (Corridor, Corner, T-Junction, Rooms).
|
||||
* Definición de dimensiones físicas y lógicas.
|
||||
* Definición de puntos de salida (Norte, Sur, Este, Oeste).
|
||||
* Asignación de texturas.
|
||||
## Sesión 1: Inicialización y Motor 3D (30 Diciembre 2025)
|
||||
|
||||
#### 3. Visualización 3D (Three.js)
|
||||
* **GameRenderer**:
|
||||
* Escena básica con iluminación ambiental y direccional.
|
||||
* **Visualización de Debug**: `GridHelper` (suelo) y `AxesHelper` (ejes).
|
||||
* **Renderizado de Baldosas**:
|
||||
* Creación de "Grill" (rejilla de alambre) para visualizar celdas individuales lógica.
|
||||
* Implementación de `TextureLoader` para cargar imágenes PNG sobre planos 3D.
|
||||
* **CameraManager**:
|
||||
* Cámara Isométrica (`OrthographicCamera`).
|
||||
* Controles de órbita fijos (N, S, E, O).
|
||||
* Zoom y Panoramización.
|
||||
* **Assets**: Integración de texturas (`.png`) para baldosas, movidas a la carpeta `public/assets` para su correcta carga en el navegador.
|
||||
### Resumen
|
||||
Establecimiento de la base completa del motor de juego con generación procedimental y visualización 3D.
|
||||
|
||||
### Estado Actual
|
||||
### Estado Actual
|
||||
### Estado Actual
|
||||
* El generador crea mazmorras y las visualiza en 3D con texturas.
|
||||
* **Problemas de Alineación**: Persisten desajustes en las conexiones de mazmorra (efecto zig-zag en puertas dobles) en la generación automática.
|
||||
* **Decisión de Diseño**: Se detiene el refinamiento de la generación automática aleatoria. El enfoque cambia a implementar la **Exploración Guiada por el Jugador**, donde la mazmorra se genera pieza a pieza según la decisión del usuario, lo que simplificará la lógica de conexión y evitará casos límite generados por el azar puro.
|
||||
|
||||
### Próximos Pasos (Siguiente Sesión)
|
||||
* Implementar al Jugador (Héroe) y su movimiento.
|
||||
* Desactivar la generación automática (`generator.step()` automático).
|
||||
* Crear UI para que el jugador elija "Explorar" en una salida específica.
|
||||
* Generar solo la siguiente pieza conectada a la salida elegida.
|
||||
* Implementar la interfaz de usuario (UI) para mostrar cartas y estado del juego.
|
||||
* Añadir modelos 3D para héroes y monstruos.
|
||||
### 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
|
||||
|
||||
Reference in New Issue
Block a user