# Guía maestra de desarrollo — Juego de plataformas 2D de banda thrash metal > 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 - Estructura mínima separada en game/, player/, enemies/ y levels/test/. - Player único con movimiento, salto, coyote time y jump buffer. - Ataque terrestre y ground pound con hitboxes reales. - Vida, daño, knockback, invulnerabilidad breve y muerte/reinicio del jugador. - CharacterData con cuatro recursos: singer, guitarist, bassist y drummer. - Los cuatro personajes usan provisionalmente las mismas animaciones idle/walk de Diego. - Primer enemigo Walker: patrulla, gira en paredes/bordes, hace daño por contacto, recibe daño y muere. - Hurtboxes y zonas de ataque visibles en modo debug con rojo semitransparente. - Sala levels/test/combat_test.tscn para probar el combate. - Controles táctiles provisionales para Android usando las mismas acciones del InputMap. - Preset Android preparado para generar un APK arm64 de pruebas. - Script scripts/export_android_debug.sh para exportar el APK desde un servidor sin GUI. ``` ## NEXT ```text - Probar y ajustar tamaños/offsets de hurtboxes e hitboxes jugando la sala de combate. - Sustituir las animaciones provisionales cuando exista arte para cada integrante. - Probar tamaños y colocación de los controles táctiles en varios teléfonos. - Añadir UI provisional de vida si hace falta para seguir afinando el combate. ``` ## 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.