diff --git a/README.md b/README.md index 82b8a9b..d239a72 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,1931 @@ -# mortal-maze-the-game +# Guía maestra de desarrollo — Juego de plataformas 2D de banda thrash metal -Proyecto de juego con godot \ No newline at end of file +> Documento vivo del proyecto. +> Su objetivo es servir como guía de desarrollo, referencia de diseño y contexto reutilizable para futuras conversaciones sobre el juego. + +--- + +# 1. Visión general + +## 1.1. Concepto + +Juego de plataformas 2D de acción, con inspiración en los Castlevania clásicos y en juegos de avance lineal por niveles. + +La temática gira alrededor de una banda de thrash metal formada por cuatro integrantes. El jugador puede controlar a cualquiera de los cuatro personajes. + +El juego estará dividido en capítulos inspirados en canciones de la banda. Cada capítulo podrá contener uno o varios niveles y, cuando tenga sentido, un enfrentamiento contra un jefe. + +El juego será principalmente lineal: + +- Se selecciona un nivel. +- Se selecciona un personaje válido para ese nivel. +- Se juega el nivel de principio a fin. +- Si el jugador muere, reinicia el nivel. +- Al completar el nivel, se desbloquea el siguiente. +- El jugador puede cambiar de personaje antes de empezar o al reintentar. + +No se plantea como un metroidvania con mapa interconectado, backtracking permanente o exploración de un único mundo grande. + +--- + +# 2. Principios de diseño del proyecto + +Estas reglas deben utilizarse para decidir qué implementar y cómo hacerlo. + +## 2.1. Primero jugabilidad, después contenido + +Antes de crear muchos enemigos, niveles, bosses, animaciones o efectos, debe existir una base jugable completa. + +Orden general: + +1. Movimiento. +2. Combate. +3. Primer enemigo. +4. Ataque especial. +5. Personajes. +6. Nivel completo. +7. Progreso. +8. Capítulos. +9. Bosses. +10. Producción de contenido. +11. Pulido. + +--- + +## 2.2. No implementar sistemas "por si acaso" + +No crear una abstracción porque podría ser útil algún día. + +Antes de añadir: + +- una clase base; +- un manager; +- un singleton; +- una state machine compleja; +- un sistema genérico; +- una jerarquía de herencia; + +debe existir un problema real que dicha abstracción resuelva. + +Regla: + +> Si la respuesta a "¿qué problema actual resuelve esto?" es "quizá lo necesite más adelante", todavía no debe implementarse. + +--- + +## 2.3. Un sistema de jugador, cuatro configuraciones + +Los cuatro personajes comparten prácticamente todo el comportamiento. + +No deben existir cuatro implementaciones diferentes de movimiento, combate, daño, salto, etc. + +Debe existir un único jugador: + +```text +Player +``` + +configurado mediante datos del personaje seleccionado: + +```text +Player + CharacterData +``` + +Ejemplo: + +```text +Player + SingerData +Player + GuitaristData +Player + BassistData +Player + DrummerData +``` + +--- + +## 2.4. Diferenciar lógica, datos y presentación + +Las diferencias entre personajes se separarán en tres categorías. + +### Diferencias visuales + +No modifican el gameplay. + +Ejemplos: + +- animación del ataque; +- sprite; +- sonido; +- partículas; +- forma visual del ataque especial. + +### Diferencias numéricas + +Cambian parámetros sin cambiar la mecánica. + +Ejemplos: + +- vida máxima; +- daño; +- velocidad; +- velocidad de carga del especial; +- radio del especial. + +Deben resolverse mediante datos/configuración. + +### Diferencias mecánicas + +Cambian realmente el comportamiento. + +Ejemplo: + +- un personaje puede volverse invisible. + +Estas diferencias sí pueden requerir código específico. + +No deben añadirse hasta que estén realmente decididas. + +--- + +# 3. Bucle principal del juego + +El flujo básico será: + +```text +Menú + ↓ +Selección de capítulo / nivel + ↓ +Selección de personaje + ↓ +Inicio del nivel + ↓ +Plataformas + enemigos + obstáculos + ↓ +Combate + ↓ +Carga del ataque especial + ↓ +Final del nivel + ↓ +Nivel completado + ↓ +Desbloqueo del siguiente nivel +``` + +En caso de muerte: + +```text +Muerte + ↓ +Reintentar + ↓ +Seleccionar personaje de nuevo + ↓ +Reiniciar nivel +``` + +--- + +# 4. Personajes jugables + +Existen cuatro personajes, correspondientes a los cuatro integrantes de la banda. + +Todos comparten las mismas capacidades principales: + +- caminar; +- saltar; +- caer; +- recibir daño; +- morir; +- ataque normal; +- ataque aéreo; +- ataque especial; +- interacción con power-ups. + +El personaje seleccionado influirá principalmente en: + +- apariencia; +- animaciones; +- efectos; +- sonidos; +- estadísticas; +- posiblemente alguna habilidad particular en el futuro. + +--- + +## 4.1. Datos configurables por personaje + +Debe existir un recurso o estructura equivalente a `CharacterData`. + +Posibles campos: + +```text +name +max_health +move_speed +jump_force + +basic_attack_damage +air_attack_damage + +special_charge_multiplier +special_max_damage +special_radius + +sprite / visual data +animation data +sound data +special visual data +``` + +No es necesario implementar todos estos parámetros desde el principio. + +Solo deben añadirse cuando sean utilizados. + +--- + +# 5. Sistema de combate + +El combate debe ser sencillo, legible y consistente. + +Inicialmente existirán tres tipos principales de ataque. + +--- + +## 5.1. Ataque normal + +Ataque terrestre básico. + +La mecánica será prácticamente idéntica para los cuatro personajes. + +Ejemplos visuales: + +- puñetazo; +- golpe con guitarra; +- golpe con bajo; +- golpe con baqueta; +- golpe con micrófono. + +La animación cambia, pero la lógica puede ser común. + +Conceptualmente: + +```text +BasicAttack + +damage +range +duration +hitbox +``` + +--- + +## 5.2. Ataque aéreo + +Ataque realizado desde el aire. + +Concepto inicial: + +- el personaje cae hacia el suelo; +- al impactar genera daño alrededor; +- puede afectar a varios enemigos próximos. + +La mecánica es común para todos los personajes. + +Solo cambia su representación visual. + +--- + +## 5.3. Ataque especial + +El jugador dispone de una barra de energía especial. + +La barra aumenta principalmente al derrotar enemigos. + +Ejemplo conceptual: + +```text +Special +████████░░ +80 % +``` + +En la primera versión del sistema: + +- la barra debe llegar al 100 %; +- entonces puede utilizarse el ataque especial; +- el ataque consume toda la carga. + +Más adelante se puede experimentar con permitir ataques parciales. + +Esto NO debe implementarse inicialmente. + +--- + +## 5.4. Daño radial del especial + +El ataque especial afecta a enemigos alrededor del jugador. + +La distancia determina el daño. + +Ejemplo: + +```text +Muy cerca -> daño máximo +Distancia media -> daño medio +Lejos -> daño reducido +Fuera del radio -> sin daño +``` + +Los cuatro personajes pueden utilizar inicialmente la misma lógica matemática. + +Lo que cambia es el efecto visual. + +Ejemplos: + +### Batería + +Platos de batería salen disparados alrededor. + +### Cantante + +Grito u onda expansiva. + +### Guitarrista + +Rayos o descargas producidas por la guitarra. + +### Bajista + +Pendiente de definir. + +Existe como idea humorística futura la posibilidad de una habilidad relacionada con "que al bajista no se le oye", por ejemplo invisibilidad. + +No debe implementarse todavía mientras no esté decidido si será realmente una habilidad diferente. + +--- + +# 6. Vida, daño y muerte + +Cada personaje tiene vida. + +La cantidad máxima puede variar entre personajes. + +Ejemplo futuro: + +```text +Singer: 100 HP +Drummer: 120 HP +``` + +Esto debe ser configuración, no código específico. + +Al recibir daño pueden existir: + +- pérdida de vida; +- animación de golpe; +- knockback; +- breve invulnerabilidad; +- muerte al llegar a cero. + +Cuando el jugador muere: + +- el nivel se reinicia; +- puede elegir otro personaje; +- se pierde el progreso temporal del nivel. + +--- + +# 7. Power-ups + +Los personajes no poseen una progresión permanente tradicional. + +No habrá inicialmente: + +- experiencia; +- niveles de personaje; +- árbol de habilidades; +- estadísticas permanentes que vayan creciendo. + +Sí podrán existir mejoras temporales. + +Ejemplo: + +```text +Púa mágica +``` + +Efecto posible: + +```text +daño normal -> daño aumentado +``` + +Duración posible: + +- hasta recibir daño; +- durante cierto tiempo; +- hasta terminar el nivel. + +Debe decidirse por cada power-up. + +Otros posibles power-ups futuros: + +- aumento de daño; +- invulnerabilidad; +- velocidad; +- curación; +- carga especial; +- ataque temporal alternativo. + +No crear un sistema universal de buffs al principio. + +Crear primero un power-up real y abstraer después si aparecen necesidades comunes. + +--- + +# 8. Niveles + +Cada nivel es independiente. + +No existe un mundo persistente interconectado. + +El jugador comienza el nivel y debe llegar hasta su final. + +Un nivel puede contener: + +- plataformas; +- enemigos; +- obstáculos; +- zonas de caída; +- power-ups; +- elementos decorativos; +- eventos; +- mini-jefes; +- jefe final del nivel, cuando corresponda. + +--- + +## 8.1. Checkpoints + +No hay checkpoints internos inicialmente. + +El propio nivel es el checkpoint. + +```text +Completas el nivel +-> queda desbloqueado el siguiente. + +Mueres +-> vuelves al principio del nivel. +``` + +--- + +## 8.2. Personajes permitidos por nivel + +Normalmente todos los personajes podrán jugar cualquier nivel. + +Sin embargo, algunos niveles pueden estar restringidos por motivos narrativos. + +Ejemplo: + +```text +allowed_characters = [ + singer, + guitarist, + bassist, + drummer +] +``` + +Nivel específico: + +```text +allowed_characters = [ + drummer +] +``` + +La restricción debe pertenecer a los datos/configuración del nivel, no estar codificada directamente en la lógica de selección. + +--- + +# 9. Capítulos + +El juego estará dividido en capítulos inspirados en canciones de la banda. + +Estructura conceptual: + +```text +Chapter 01 — Canción A +├── Level 01 +├── Level 02 +├── Level 03 +└── Boss + +Chapter 02 — Canción B +├── Level 01 +├── Level 02 +└── Boss +``` + +No todos los capítulos necesitan tener el mismo número de niveles. + +Debe evitarse imponer una estructura rígida como: + +```text +cada canción = exactamente 3 niveles + boss +``` + +El contenido debe determinar la duración del capítulo. + +--- + +# 10. Enemigos + +La temática permite una gran variedad de enemigos. + +Podrán existir: + +- personas; +- monstruos; +- criaturas absurdas; +- objetos animados; +- enemigos humorísticos; +- enemigos relacionados con la canción o escenario. + +El objetivo inicial no es crear muchos. + +Primero deben crearse enemigos sencillos que permitan validar el combate. + +Orden recomendado: + +### Enemigo 1 + +Camina y hace daño al tocar al jugador. + +### Enemigo 2 + +Vuela y persigue al jugador. + +### Enemigo 3 + +Permanece a distancia y lanza ataques. + +Solo después de disponer de varios enemigos deben extraerse sistemas comunes. + +--- + +# 11. Bosses + +Los bosses pueden ser muy diferentes entre sí. + +Podrán existir: + +- personas; +- monstruos; +- criaturas temáticas; +- enemigos humorísticos. + +El boss final del juego será: + +```text +LA MUERTE +``` + +No debe crearse un `BossSystem` genérico antes de hacer el primer boss real. + +Primero se implementa un boss. + +Después se analiza qué partes merecen reutilizarse. + +Posibles conceptos que aparecerán: + +- barra de vida; +- arena; +- fases; +- patrones de ataque; +- cambios de comportamiento; +- eventos al morir. + +--- + +# 12. Arquitectura inicial recomendada en Godot + +## 12.1. Player + +Escena conceptual: + +```text +Player +├── Sprite / AnimatedSprite +├── CollisionShape +├── Hurtbox +├── AttackOrigin +├── AnimationPlayer +└── Camera +``` + +La composición real se decidirá mientras se implemente. + +No añadir nodos sin necesidad. + +--- + +## 12.2. CharacterData + +Los datos particulares de cada personaje deben mantenerse fuera de la lógica general del jugador. + +Conceptualmente: + +```text +player/ +├── player.tscn +├── player.gd +├── character_data.gd +└── characters/ + ├── singer/ + ├── guitarist/ + ├── bassist/ + └── drummer/ +``` + +Posibles recursos: + +```text +singer.tres +guitarist.tres +bassist.tres +drummer.tres +``` + +--- + +## 12.3. Ataques + +Inicialmente: + +```text +attacks/ +├── basic_attack/ +├── air_attack/ +└── special_attack/ +``` + +No crear una jerarquía sofisticada de clases hasta comprobar qué comparten realmente. + +--- + +## 12.4. Hitbox y Hurtbox + +Estos sí son buenos candidatos a convertirse en elementos reutilizables porque múltiples entidades necesitan: + +```text +atacar +recibir ataques +``` + +Por ejemplo: + +```text +Player +Enemy +Boss +Projectile +Trap +``` + +pueden compartir esos conceptos. + +--- + +# 13. Estructura de carpetas recomendada + +Estructura objetivo aproximada: + +```text +res:// + +├── game/ +│ ├── main.tscn +│ └── game.gd +│ +├── player/ +│ ├── player.tscn +│ ├── player.gd +│ ├── character_data.gd +│ │ +│ ├── characters/ +│ │ ├── singer/ +│ │ │ ├── singer.tres +│ │ │ ├── sprites/ +│ │ │ └── animations/ +│ │ │ +│ │ ├── guitarist/ +│ │ ├── bassist/ +│ │ └── drummer/ +│ │ +│ └── attacks/ +│ ├── basic_attack/ +│ ├── air_attack/ +│ └── special_attack/ +│ +├── combat/ +│ ├── hitbox.gd +│ └── hurtbox.gd +│ +├── enemies/ +│ ├── common/ +│ ├── enemy_01/ +│ ├── enemy_02/ +│ └── bosses/ +│ +├── levels/ +│ ├── test/ +│ │ └── combat_test.tscn +│ │ +│ └── chapters/ +│ ├── chapter_01/ +│ │ ├── level_01.tscn +│ │ ├── level_02.tscn +│ │ └── boss.tscn +│ │ +│ └── chapter_02/ +│ +├── pickups/ +│ ├── health/ +│ ├── damage_boost/ +│ └── special_charge/ +│ +├── ui/ +│ ├── hud/ +│ ├── character_select/ +│ ├── level_select/ +│ └── menus/ +│ +├── systems/ +│ ├── progression/ +│ ├── save/ +│ └── audio/ +│ +└── assets/ + ├── audio/ + ├── fonts/ + ├── tilesets/ + ├── effects/ + └── shared/ +``` + +Esta estructura representa hacia dónde puede crecer el proyecto. + +NO es obligatorio crear todas estas carpetas al principio. + +Estructura mínima inicial: + +```text +res:// +├── game/ +├── player/ +├── combat/ +├── enemies/ +├── levels/ +├── ui/ +└── assets/ +``` + +Las nuevas carpetas aparecen cuando existe contenido real que guardar en ellas. + +--- + +# 14. Organización de escenas y recursos + +Cuando una entidad tenga recursos específicos, mantenerlos próximos. + +Ejemplo: + +```text +enemies/ +└── skeleton/ + ├── skeleton.tscn + ├── skeleton.gd + ├── sprites/ + ├── animations/ + └── sounds/ +``` + +Evitar separar sistemáticamente por tipo: + +```text +scripts/enemies/ +scenes/enemies/ +sprites/enemies/ +sounds/enemies/ +``` + +si eso obliga a recorrer medio proyecto para modificar una sola entidad. + +Los recursos verdaderamente compartidos sí pueden ir en `assets/`. + +--- + +# 15. Autoloads / singletons + +Utilizar muy pocos. + +Posibles candidatos futuros: + +```text +Game +SaveManager +AudioManager +``` + +Solo deben existir si realmente necesitan ser globales. + +Evitar crear: + +```text +PlayerManager +EnemyManager +WeaponManager +DoorManager +AnimationManager +AttackManager +``` + +sin una necesidad concreta. + +--- + +# 16. Convenciones de código + +## 16.1. Nombres simples + +Preferir: + +```text +player.gd +hitbox.gd +hurtbox.gd +checkpoint.gd +skeleton.gd +``` + +Evitar nombres excesivamente abstractos como: + +```text +generic_actor_controller.gd +advanced_character_system.gd +dynamic_entity_manager.gd +``` + +--- + +## 16.2. Código antes que arquitectura perfecta + +El proyecto debe ser fácil de entender. + +No necesita parecer una librería genérica. + +Una función o clase debe tener una responsabilidad útil y real. + +Evitar wrappers que solo reenvían llamadas sin añadir comportamiento. + +--- + +## 16.3. No separar prematuramente + +Es perfectamente aceptable que `player.gd` contenga inicialmente: + +```text +input +movement +jump +attack +damage +death +``` + +Cuando alguna parte crezca demasiado o sea compartida por otras entidades, entonces se extrae. + +--- + +# 17. Sala de pruebas + +Debe existir una escena específica: + +```text +levels/test/combat_test.tscn +``` + +Su finalidad es probar mecánicas rápidamente. + +Puede ser visualmente fea. + +Debe incluir progresivamente: + +- suelo; +- plataformas; +- desniveles; +- paredes; +- agujero; +- enemigos; +- dummy de pruebas; +- zonas donde probar ataques; +- espacio suficiente para probar cámara. + +No probar todas las mecánicas nuevas dentro de niveles reales. + +--- + +# 18. Roadmap de desarrollo + +--- + +## FASE 0 — Preparación del proyecto + +Objetivo: + +Tener un proyecto limpio y controlado. + +Tareas: + +- [ ] Crear estructura mínima de carpetas. +- [ ] Configurar resolución. +- [ ] Configurar Input Map. +- [ ] Crear `main.tscn`. +- [ ] Crear `combat_test.tscn`. +- [ ] Inicializar Git. +- [ ] Crear `.gitignore` apropiado para Godot. +- [ ] Comprobar que el proyecto arranca desde una escena principal sencilla. + +No hacer todavía: + +- sistema de guardado; +- personajes definitivos; +- animaciones finales; +- menús completos. + +--- + +## FASE 1 — Movimiento del jugador + +Objetivo: + +Que controlar al personaje resulte correcto. + +Tareas: + +- [ ] Movimiento horizontal. +- [ ] Salto. +- [ ] Gravedad. +- [ ] Colisión con suelo. +- [ ] Colisión con paredes. +- [ ] Caída. +- [ ] Dirección izquierda/derecha. +- [ ] Cámara. +- [ ] Reinicio al caer fuera del nivel. + +Pruebas: + +- [ ] Saltar desde parado. +- [ ] Saltar mientras se corre. +- [ ] Cambiar de dirección. +- [ ] Caer desde diferentes alturas. +- [ ] Chocar con paredes. +- [ ] Llegar a bordes de plataformas. +- [ ] Comprobar que la cámara no produce comportamientos incómodos. + +No avanzar hasta que el movimiento sea agradable. + +--- + +## FASE 2 — Sensación del movimiento + +Objetivo: + +Convertir movimiento funcional en movimiento agradable. + +Posibles ajustes: + +- [ ] aceleración; +- [ ] deceleración; +- [ ] velocidad máxima; +- [ ] fuerza de salto; +- [ ] gravedad; +- [ ] control aéreo; +- [ ] coyote time, si se considera útil; +- [ ] jump buffering, si se considera útil. + +No añadir características porque otros juegos las tengan. + +Añadirlas solo si mejoran el control. + +--- + +## FASE 3 — Combate básico + +Objetivo: + +Poder atacar y hacer daño. + +Tareas: + +- [ ] Ataque terrestre. +- [ ] Hitbox. +- [ ] Hurtbox. +- [ ] Daño. +- [ ] Vida. +- [ ] Recibir daño. +- [ ] Knockback. +- [ ] Invulnerabilidad breve tras recibir daño. +- [ ] Muerte. +- [ ] Dummy inmóvil para pruebas. + +Pruebas: + +- [ ] Un ataque golpea una sola vez cuando debe. +- [ ] No se hace daño fuera del alcance. +- [ ] El jugador recibe daño correctamente. +- [ ] La invulnerabilidad evita golpes encadenados accidentales. +- [ ] La muerte ocurre al llegar a cero. +- [ ] Reiniciar deja el estado limpio. + +--- + +## FASE 4 — Ataque aéreo + +Objetivo: + +Implementar el segundo ataque común. + +Tareas: + +- [ ] Detectar uso desde el aire. +- [ ] Caída ofensiva. +- [ ] Impacto contra suelo. +- [ ] Área de daño. +- [ ] Evitar activaciones no válidas. +- [ ] Animación provisional. + +Pruebas: + +- [ ] Uso desde diferentes alturas. +- [ ] Impacto con varios enemigos. +- [ ] Uso próximo a paredes. +- [ ] Uso sobre plataformas estrechas. +- [ ] Evitar quedarse bloqueado en un estado incorrecto. + +--- + +## FASE 5 — Primer enemigo + +Objetivo: + +Crear el primer combate real. + +Primer enemigo recomendado: + +```text +Camina. +Puede hacer daño. +Recibe daño. +Muere. +``` + +Tareas: + +- [ ] Movimiento. +- [ ] Vida. +- [ ] Hurtbox. +- [ ] Ataque/contacto. +- [ ] Muerte. +- [ ] Avisar al jugador/sistema cuando muere. + +Pruebas: + +- [ ] Ataque normal. +- [ ] Ataque aéreo. +- [ ] Recibir daño del enemigo. +- [ ] Varios enemigos simultáneos. +- [ ] Muerte del enemigo. +- [ ] Reinicio de nivel. + +--- + +## FASE 6 — Barra y ataque especial + +Objetivo: + +Cerrar el bucle básico del combate. + +Tareas: + +- [ ] Añadir barra especial. +- [ ] Aumentar carga al matar enemigos. +- [ ] Definir carga máxima. +- [ ] Bloquear uso si no está cargada. +- [ ] Ataque radial. +- [ ] Daño dependiente de distancia. +- [ ] Consumir la carga tras usarlo. +- [ ] Representación provisional sencilla. + +Primera implementación: + +```text +Solo usable al 100 %. +``` + +No implementar todavía carga parcial. + +Pruebas: + +- [ ] Matar enemigo carga correctamente. +- [ ] No puede superar máximo. +- [ ] No puede usarse antes de tiempo. +- [ ] El especial afecta solo dentro del radio. +- [ ] El daño disminuye con distancia. +- [ ] Varios enemigos reciben daño correctamente. +- [ ] La barra vuelve a cero. + +--- + +## FASE 7 — Sistema de personajes + +Objetivo: + +Demostrar que un solo `Player` puede representar a los cuatro miembros. + +Primero implementar DOS personajes. + +Ejemplo: + +```text +Singer +Drummer +``` + +Tareas: + +- [ ] Crear `CharacterData`. +- [ ] Cargar datos en `Player`. +- [ ] Cambiar vida máxima. +- [ ] Cambiar estadísticas simples. +- [ ] Cambiar sprite/animaciones provisionales. +- [ ] Seleccionar personaje antes de jugar. +- [ ] Cambiar personaje tras morir. + +Validación fundamental: + +> Cambiar de personaje NO debe requerir modificar `player.gd`. + +Cuando funcione con dos: + +- [ ] Añadir Guitarist. +- [ ] Añadir Bassist. + +--- + +## FASE 8 — Primer nivel completo + +Objetivo: + +Construir por primera vez una experiencia con principio y final. + +El nivel debe incluir: + +- [ ] punto inicial; +- [ ] plataformas; +- [ ] varias situaciones de movimiento; +- [ ] enemigos; +- [ ] al menos un power-up provisional; +- [ ] final del nivel; +- [ ] muerte; +- [ ] reinicio; +- [ ] victoria. + +Todavía puede utilizar gráficos provisionales. + +El objetivo es validar el flujo. + +--- + +## FASE 9 — Power-up real + +Objetivo: + +Implementar una mejora temporal sencilla. + +Ejemplo recomendado: + +```text +DamageBoost +``` + +Tareas: + +- [ ] Pickup en el escenario. +- [ ] Detectar recogida. +- [ ] Aumentar daño. +- [ ] Definir cuándo termina. +- [ ] Restaurar estado correctamente. +- [ ] Reinicio correcto al morir. + +No crear todavía un sistema universal de buffs. + +--- + +## FASE 10 — Selección de personaje y nivel + +Objetivo: + +Construir el flujo del juego. + +Tareas: + +- [ ] Pantalla de selección de nivel. +- [ ] Pantalla de selección de personaje. +- [ ] Mostrar personajes permitidos. +- [ ] Entrar al nivel. +- [ ] Reintentar. +- [ ] Cambiar personaje tras morir. +- [ ] Volver al selector cuando corresponda. + +--- + +## FASE 11 — Progresión + +Objetivo: + +Poder jugar varios niveles en orden. + +Tareas: + +- [ ] Estado de nivel bloqueado/desbloqueado. +- [ ] Completar nivel. +- [ ] Desbloquear siguiente. +- [ ] Mostrar estado en selector. +- [ ] Guardado mínimo del progreso. + +Datos mínimos que probablemente deban persistir: + +```text +niveles completados +niveles desbloqueados +``` + +Opcional: + +```text +último personaje seleccionado +``` + +No guardar todavía información que no sea necesaria. + +--- + +## FASE 12 — Primer capítulo + +Objetivo: + +Crear una pequeña versión representativa del juego. + +Ejemplo: + +```text +Capítulo / Canción +├── Nivel 1 +├── Nivel 2 +├── Nivel 3 +└── Boss +``` + +No es obligatorio que tenga exactamente esa estructura. + +El objetivo es comprobar que todo funciona unido. + +--- + +## FASE 13 — Primer boss + +Objetivo: + +Descubrir qué necesita realmente el sistema de bosses. + +Tareas posibles: + +- [ ] vida de boss; +- [ ] HUD de boss; +- [ ] arena; +- [ ] patrón 1; +- [ ] patrón 2; +- [ ] muerte; +- [ ] final del nivel; +- [ ] transición posterior. + +No crear abstracciones de boss antes de esta fase. + +--- + +## FASE 14 — Producción de contenido + +Solo después de tener una vertical slice completa. + +Crear progresivamente: + +- nuevos enemigos; +- nuevos niveles; +- bosses; +- power-ups; +- variantes; +- escenarios; +- capítulos; +- animaciones; +- efectos. + +A partir de aquí se pasa de: + +> construir los sistemas del juego + +a: + +> fabricar contenido utilizando esos sistemas. + +--- + +## FASE 15 — Pulido + +Al final o cuando una mecánica ya esté estable: + +- animaciones finales; +- partículas; +- efectos; +- screenshake; +- sonido; +- música; +- iluminación; +- shaders; +- UI final; +- transiciones; +- efectos de impacto; +- feedback visual; +- secretos; +- easter eggs. + +--- + +# 19. Vertical slice objetivo + +Antes de producir el juego completo debe existir una pequeña versión terminada. + +Objetivo recomendado: + +```text +Selección de personaje + ↓ +Nivel 1 + ↓ +Nivel 2 + ↓ +Boss + ↓ +Capítulo completado +``` + +Debe contener: + +- los cuatro personajes funcionales; +- movimiento; +- ataque normal; +- ataque aéreo; +- especial; +- vida; +- muerte; +- selección; +- enemigos; +- power-up; +- progreso; +- boss; +- UI básica; +- sonido básico. + +No necesita gráficos definitivos. + +Si esta versión funciona y resulta divertida, la base está preparada para crecer. + +--- + +# 20. Estrategia de pruebas + +Las pruebas se dividirán en varios niveles. + +## 20.1. Prueba aislada + +Probar una mecánica concreta en `combat_test.tscn`. + +Ejemplos: + +- salto; +- hitbox; +- daño; +- ataque aéreo; +- especial; +- power-up. + +--- + +## 20.2. Prueba combinada + +Comprobar interacciones entre sistemas. + +Ejemplos: + +```text +ataque + enemigo +ataque aéreo + plataforma +power-up + daño +especial + varios enemigos +muerte + cambio de personaje +``` + +--- + +## 20.3. Prueba de nivel + +Jugar un nivel completo varias veces. + +Comprobar: + +- que puede terminarse; +- que no existen bloqueos; +- que morir reinicia todo correctamente; +- que el personaje seleccionado se aplica bien; +- que los enemigos se reinician; +- que los power-ups no quedan activos; +- que la barra especial tiene el estado esperado. + +--- + +## 20.4. Prueba de flujo completo + +```text +Menú +-> selección +-> nivel +-> muerte +-> reintento +-> cambio de personaje +-> completar +-> desbloqueo +-> siguiente nivel +``` + +Estas pruebas son fundamentales antes de producir muchos niveles. + +--- + +# 21. Qué NO implementar todavía + +Mantener esta lista visible. + +No implementar hasta que exista una necesidad real: + +- inventario complejo; +- árbol de habilidades; +- experiencia; +- niveles de personaje; +- estadísticas permanentes; +- mapa interconectado; +- backtracking; +- sistema genérico de bosses; +- cuatro clases diferentes de jugador; +- state machine excesivamente compleja; +- sistema universal de buffs; +- sistema universal de armas; +- diálogo complejo; +- sistema de quests; +- guardado de decenas de variables; +- arquitectura preparada para mecánicas todavía inexistentes. + +--- + +# 22. Gestión del trabajo + +Utilizar siempre tres grupos. + +## NOW + +Lo que se está desarrollando actualmente. + +Debe ser pequeño. + +Ejemplo: + +```text +NOW + +- terminar ataque normal; +- enemigo recibe daño; +- enemigo muere. +``` + +--- + +## NEXT + +Lo siguiente cuando `NOW` esté terminado. + +Ejemplo: + +```text +NEXT + +- jugador recibe daño; +- knockback; +- muerte. +``` + +--- + +## LATER + +Ideas interesantes que no deben interrumpir el trabajo actual. + +Ejemplo: + +```text +LATER + +- invisibilidad del bajista; +- easter eggs; +- nuevos power-ups; +- enemigo especial; +- boss concreto; +- shaders; +- ataque especial alternativo. +``` + +Cuando aparezca una idea nueva: + +1. escribirla; +2. clasificarla; +3. continuar con `NOW`. + +--- + +# 23. Git + +Utilizar Git desde el principio. + +Commits pequeños y descriptivos. + +Buenos ejemplos: + +```text +Add basic player movement +Add player jump +Add player basic attack +Add enemy health +Add special meter +Add character data resource +``` + +Evitar: + +```text +changes +stuff +various fixes +cosas +``` + +No realizar cambios gigantes sin puntos de retorno. + +--- + +# 24. Filosofía para aprender mientras se desarrolla + +Este proyecto también es una herramienta de aprendizaje. + +No intentar dominar simultáneamente: + +- arquitectura avanzada; +- shaders; +- pixel art; +- IA compleja; +- game design; +- animación; +- audio; +- optimización; +- sistemas genéricos. + +Aprender cada concepto cuando el proyecto lo necesite. + +Es preferible una solución sencilla y comprensible que una arquitectura técnicamente sofisticada difícil de mantener. + +--- + +# 25. Decisiones todavía abiertas + +Estas cuestiones pueden decidirse más adelante. + +No bloquean el desarrollo actual. + +## Ataque especial + +Pendiente decidir si: + +- solo puede usarse al 100 %; +- puede utilizarse con carga parcial; +- la carga parcial modifica daño/radio. + +Primera implementación recomendada: + +```text +solo al 100 % +``` + +--- + +## Diferencias reales entre personajes + +Actualmente se considera que comparten todas las mecánicas. + +Pueden añadirse más adelante diferencias como: + +- vida; +- carga especial; +- daño; +- velocidad; +- peculiaridades concretas. + +Idea pendiente: + +```text +Bajista -> invisibilidad +``` + +No implementar hasta decidir que realmente forma parte del diseño. + +--- + +## Power-ups + +Pendiente definir: + +- duración; +- pérdida al recibir daño; +- pérdida al morir; +- pérdida al terminar nivel. + +Se decidirá por power-up. + +--- + +## Estructura exacta de capítulos + +Pendiente definir: + +- número de niveles por canción; +- bosses por capítulo; +- capítulos cortos/largos; +- niveles especiales. + +No imponer todavía una cantidad fija. + +--- + +## UI de vida + +Pendiente decidir: + +- barra; +- corazones; +- iconos; +- otro sistema. + +No afecta a la arquitectura inicial. + +--- + +# 26. Contexto resumido para futuras conversaciones con ChatGPT + +Esta sección debe mantenerse actualizada. + +Puede utilizarse para devolver rápidamente el contexto del proyecto. + +--- + +## Proyecto + +Juego 2D de plataformas y acción en Godot inspirado en Castlevania clásico. + +Temática: + +```text +banda de thrash metal +``` + +Cuatro personajes jugables: + +```text +los cuatro integrantes de la banda +``` + +--- + +## Estructura + +Juego lineal por niveles. + +No es un metroidvania. + +```text +Capítulo / canción + ↓ +uno o varios niveles + ↓ +posible boss +``` + +Al completar un nivel se desbloquea el siguiente. + +Al morir se reinicia el nivel. + +El personaje puede cambiarse antes de empezar o al reintentar. + +Algunos niveles pueden restringir qué personajes pueden jugarse por motivos narrativos. + +--- + +## Jugador + +Un único sistema `Player`. + +Los cuatro personajes reutilizan: + +- movimiento; +- salto; +- vida; +- daño; +- ataque normal; +- ataque aéreo; +- ataque especial; +- muerte. + +Las diferencias deben modelarse principalmente mediante `CharacterData`. + +--- + +## Ataques + +### Ataque normal + +Igual mecánicamente para todos. + +Diferentes animaciones. + +### Ataque aéreo + +Caída/impacto contra el suelo con daño de área. + +Igual mecánicamente para todos. + +### Especial + +Se carga derrotando enemigos. + +Primera versión: + +```text +solo usable al 100 % +``` + +Ataque radial. + +Más daño cuanto más cerca está el enemigo. + +Visual diferente por personaje. + +Ideas: + +```text +Batería -> platos. +Cantante -> grito. +Guitarrista -> rayos. +Bajista -> pendiente. +``` + +--- + +## Progresión + +No hay progresión permanente del personaje inicialmente. + +Sí existen power-ups temporales. + +Ejemplo: + +```text +púa mágica -> aumento temporal de daño +``` + +--- + +## Enemigos + +Mezcla libre: + +- personas; +- monstruos; +- objetos con vida; +- enemigos humorísticos. + +--- + +## Bosses + +Variados. + +Boss final: + +```text +La Muerte +``` + +--- + +## Filosofía técnica + +- YAGNI. +- Simplicidad. +- Evitar abstracciones prematuras. +- No duplicar código entre personajes. +- No crear managers sin necesidad. +- No generalizar antes de tener varios casos reales. +- Primero vertical slice, después producción de contenido. + +--- + +# 27. Estado actual del desarrollo + +Actualizar esta sección conforme avance el proyecto. + +## NOW + +```text +Pendiente de establecer según el estado real del proyecto. +``` + +## NEXT + +```text +Pendiente. +``` + +## LATER + +```text +- diferencias particulares entre personajes; +- invisibilidad del bajista; +- power-ups adicionales; +- definición completa de capítulos; +- bosses; +- easter eggs; +- polish visual. +``` + +--- + +# 28. Cómo actualizar este documento + +Cuando se tome una decisión importante: + +1. actualizar la sección correspondiente; +2. eliminar decisiones que ya no sean válidas; +3. actualizar `Estado actual del desarrollo`; +4. actualizar `Contexto resumido para futuras conversaciones con ChatGPT`. + +Este documento debe representar el proyecto actual, no su historia completa. + +Si una idea se descarta, debe desaparecer de las secciones principales. + +Puede mantenerse únicamente en un backlog si sigue siendo una posibilidad futura. + +--- + +# 29. Regla final + +Antes de empezar cualquier tarea nueva, preguntar: + +> ¿Esto ayuda directamente a completar la siguiente versión jugable? + +Si la respuesta es no: + +```text +LATER +``` + +El objetivo principal es siempre tener una versión pequeña pero completamente jugable antes de ampliar el alcance.