mmo/module.md

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