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:

Movimiento.
Combate.
Primer enemigo.
Ataque especial.
Personajes.
Nivel completo.
Progreso.
Capítulos.
Bosses.
Producción de contenido.
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:

Player

configurado mediante datos del personaje seleccionado:

Player + CharacterData

Ejemplo:

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á:

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:

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:

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:

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:

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:

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:

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:

Púa mágica

Efecto posible:

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.

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:

allowed_characters = [
    singer,
    guitarist,
    bassist,
    drummer
]

Nivel específico:

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:

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:

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á:

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:

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:

player/
├── player.tscn
├── player.gd
├── character_data.gd
└── characters/
    ├── singer/
    ├── guitarist/
    ├── bassist/
    └── drummer/

Posibles recursos:

singer.tres
guitarist.tres
bassist.tres
drummer.tres

12.3. Ataques

Inicialmente:

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:

atacar
recibir ataques

Por ejemplo:

Player
Enemy
Boss
Projectile
Trap

pueden compartir esos conceptos.

13. Estructura de carpetas recomendada

Estructura objetivo aproximada:

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:

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:

enemies/
└── skeleton/
    ├── skeleton.tscn
    ├── skeleton.gd
    ├── sprites/
    ├── animations/
    └── sounds/

Evitar separar sistemáticamente por tipo:

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:

Game
SaveManager
AudioManager

Solo deben existir si realmente necesitan ser globales.

Evitar crear:

PlayerManager
EnemyManager
WeaponManager
DoorManager
AnimationManager
AttackManager

sin una necesidad concreta.

16. Convenciones de código

16.1. Nombres simples

Preferir:

player.gd
hitbox.gd
hurtbox.gd
checkpoint.gd
skeleton.gd

Evitar nombres excesivamente abstractos como:

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:

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:

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:

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:

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:

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:

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:

niveles completados
niveles desbloqueados

Opcional:

ú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:

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

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:

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:

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

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:

NOW

- terminar ataque normal;
- enemigo recibe daño;
- enemigo muere.

Lo siguiente cuando NOW esté terminado.

Ejemplo:

NEXT

- jugador recibe daño;
- knockback;
- muerte.

LATER

Ideas interesantes que no deben interrumpir el trabajo actual.

Ejemplo:

LATER

- invisibilidad del bajista;
- easter eggs;
- nuevos power-ups;
- enemigo especial;
- boss concreto;
- shaders;
- ataque especial alternativo.

Cuando aparezca una idea nueva:

escribirla;
clasificarla;
continuar con NOW.

23. Git

Utilizar Git desde el principio.

Commits pequeños y descriptivos.

Buenos ejemplos:

Add basic player movement
Add player jump
Add player basic attack
Add enemy health
Add special meter
Add character data resource

Evitar:

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:

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:

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:

banda de thrash metal

Cuatro personajes jugables:

los cuatro integrantes de la banda

Estructura

Juego lineal por niveles.

No es un metroidvania.

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:

solo usable al 100 %

Ataque radial.

Más daño cuanto más cerca está el enemigo.

Visual diferente por personaje.

Ideas:

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:

púa mágica -> aumento temporal de daño

Enemigos

Mezcla libre:

personas;
monstruos;
objetos con vida;
enemigos humorísticos.

Bosses

Variados.

Boss final:

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

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

- 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

- 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:

actualizar la sección correspondiente;
eliminar decisiones que ya no sean válidas;
actualizar Estado actual del desarrollo;
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:

LATER

El objetivo principal es siempre tener una versión pequeña pero completamente jugable antes de ampliar el alcance.