1947 lines
33 KiB
Markdown
1947 lines
33 KiB
Markdown
# 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.
|