This commit is contained in:
Marek Lenczewski
2026-04-16 15:11:15 +02:00
parent f1d34ebf1d
commit cf5979803e
3 changed files with 227 additions and 15 deletions

114
module.md Normal file
View File

@@ -0,0 +1,114 @@
# Module — Implementierungs-Schritte zum Prototyp
Jedes Modul ist ein self-contained Inkrement. Nach jedem Modul ist der Prototyp spielbarer als vorher. Pro Modul: planen → zeigen → implementieren → testen.
## M1 — Ist-Stand-Audit ✓
Existierender Code gegen `plan.md` abgeglichen. Ergebnis: Core-Loop zu ~60% da, aber große Abweichungen in Autoload- und System-Struktur. Siehe M1b.
## M1b — Architektur-Refactor
Ist-Stand an `plan.md` angleichen, bevor neue Features gebaut werden. Jeder Sub-Schritt einzeln testen.
### Sub-Schritte
1. **Zentraler `stats.gd` Autoload**
- Neue Datei `autoloads/stats.gd` mit API: `register(entity, resource)`, `get(entity, stat_name)`, `set(entity, stat_name, value)`, `deregister(entity)`
- Hält Dictionary[Node, Dictionary] für Laufzeit-Werte aller Entities
- Migration: player_stats.gd, enemy_stats.gd, boss_stats.gd, portal_stats.gd → alle Lese-/Schreib-Stellen auf zentrales `Stats` umstellen
- Entity-Registrierungs-Pattern: `_ready() → Stats.register(self, stats_resource)`, `_exit_tree() → Stats.deregister(self)`
- player_cache (für Szenenwechsel) in Stats
2. **`game_state.gd` Autoload**
- Neue Datei `autoloads/game_state.gd`
- Speichert: current_role, player_position, current_wave (später)
- Wird von Szenen gelesen beim Laden
3. **Systeme → Szenen-Skripte umziehen**
- `systems/role_system.gd` entfernen, Logik nach `scenes/player/role/role.gd` (prüfen: schon da?)
- `systems/targeting_system.gd` entfernen, Logik nach `scenes/player/targeting.gd`
- `systems/hud_system.gd` entfernen, Logik in `scenes/hud/hud_*.gd` (vitals, respawn, abilities, effects)
- `systems/nameplate_system.gd` entfernen, in Enemy-Szene integrieren
- `systems/portal_system.gd` entfernen, Logik in `scenes/portal/init.gd` / `portal.gd`
- `systems/dungeon_system.gd` entfernen, Logik in `scenes/dungeon/dungeon_manager.gd`
- Alle Signal-Verdrahtungen anpassen
4. **Effect-Hierarchie aufräumen**
- `buff_system.gd` + `debuff_system.gd` → Children von `effect_system.gd`
- Neuer `buff_calc_system.gd` als Child von `effect_system.gd` (aggregiert Multiplier → Stats/Shield)
5. **`attack_system.gd` vs `ability_system.gd`**
- Rollen klären: Ability-Trigger + Schaden-Applikation
- Wahrscheinlich: `attack_system.gd` = AutoAttack-Loop (_process-driven), `ability_system.gd` = Ability-Execution bei Input
- Falls Duplikat: mergen. Falls getrennt: umbenennen zu `auto_attack_system.gd` wie plan.md
6. **Core-Loop-Test nach Refactor**
- Godot starten, Portal angreifen, Dungeon betreten, Boss besiegen, zur Taverne zurück
- Rollen-Wechsel testen, alle Abilities, Respawn, Effekte
- Keine Regressions
7. **`plan.md` finalisieren**
- Ungenaue Referenzen (`combat.gd`, `combat_state.gd`, `enemy_movement.gd`) durch Ist-Skripte ersetzen
- System-Liste auf tatsächliche Anzahl anpassen
- Autoload-Sektion final
## M2 — Startmenü
- `scenes/menu/main_menu.tscn` — Buttons: Singleplayer, Host, Join, Quit
- Singleplayer → `world.tscn`; Host/Join zunächst disabled (bis M11)
- `project.godot`: main_scene = main_menu
## M3 — Taverne als Entity mit HP
- `TavernStats` Resource (nur `max_health`)
- Taverne-Node: `HitArea` (Area3D), `Healthbar`, registriert bei Stats
- HUD: Tavern-HP oben mittig
- Taverne HP = 10 × normales Portal HP
## M4 — WaveSystem (Basis)
- `wave_system.gd`: Timer (1h), Wellen-Counter
- PortalSpawner refactoren: immer max 3 normale (sofort nachspawnen)
- HUD: Wellen-Nummer + Restzeit oben
## M5 — Rotes Portal
- `PortalStats.variant` = NORMAL | RED
- Rotes Portal: 10× HP, rote Mesh, Gruppe `red_portal`
- WaveSystem spawnt 1 rotes pro Welle, nach Besieg → nächste Welle + neues rotes
- Dungeon-Gegner des roten Portals: 10× stärker
## M6 — XP + Level-System
- `PlayerStats`: `level, xp, xp_to_next`
- `xp_system.gd`: XP bei Dungeon-Clear (1 normal, 10 rot)
- Fibonacci-Level-Kurve
- Level-Up: alle PlayerStats × 2, aktuelle HP/Schild auf neues Max
- HUD: XP-Balken + Level-Label
## M7 — Gegner-Skalierung
- EnemyStats × 2^(player_level1) bei Spawn
- Rotes Portal: zusätzlich × 10
## M8 — InvasionSystem + Game-Over
- Timer-Ablauf ohne rotes Portal besiegt: InvasionSystem aktiviert
- Alle noch lebenden Gegner des roten Portals brechen aus, spawnen am Rand, laufen zur Taverne
- Schaden an Taverne über HealthSystem
- Alle tot → `invasion_ended(true)` → nächste Welle + neues rotes
- Taverne HP 0 → `tavern_destroyed` → Game-Over-Overlay → 3s Delay → Reset: Level 1, Welle 1, Stats Base, zurück ins Startmenü oder neuer Run
## M9 — Modelle + Animationen
- Einfache 3D-Modelle (Mixamo / Kenney / KayKit) für Spieler, Gegner, Boss, Portal, Taverne
- Animationen: Idle, Walk, Attack, Death
- Simple Shader (unlit oder lite-PBR mit Emissive für Portale)
## M10 — Audio
- Musik: Taverne (ruhig), Kampf, Invasion (bedrohlich)
- SFX: Ability-Cast, Hit, Death, Portal-Spawn, Level-Up, Invasion-Alarm, Taverne-Schaden
- Quellen: frei zugängliche CC0-Packs (freesound, OpenGameArt) — wird pro Sound dokumentiert
## M11 — Multiplayer P2P
- `ENetMultiplayerPeer` — Host öffnet Port, Client joint via IP
- `MultiplayerSpawner` für Spieler + Gegner
- `MultiplayerSynchronizer` für Stats-Felder
- Authoritative Host: Wave/Invasion/Taverne-State liegt beim Host
- Shared World (1 Taverne, alle Spieler verteidigen gemeinsam)
- Startmenü: Host/Join aktivieren
## Reihenfolge-Begründung
- M1 klärt Ist-Stand (verhindert doppelte Arbeit)
- M2M8 bringen den Run-Loop zum Laufen (Kernspiel komplett spielbar)
- M9M10 machen es „erlebbar" (Look + Feel)
- M11 als Letztes — größter Brocken, baut auf stabilem Core auf