# 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_level−1) 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)
- M2–M8 bringen den Run-Loop zum Laufen (Kernspiel komplett spielbar)
- M9–M10 machen es „erlebbar" (Look + Feel)
- M11 als Letztes — größter Brocken, baut auf stabilem Core auf