# MMO Projekt

## Überblick
Community-MMO in Godot 4.6 (Forward+, Jolt Physics). Ziel: Einsamkeit bekämpfen durch geographische Nähe der Spieler. Stilles Designprinzip — nicht als "Anti-Einsamkeits-Spiel" vermarktet.

## Sprache
Der User kommuniziert auf Deutsch. Code und Variablen auf Englisch. Kommentare nur wo nötig.

## Code-Style
- GDScript mit 2 Spaces Einrückung (Godot Editor auf Spaces/2 eingestellt)
- Explizite Typen bei Variablen die von Variant-Funktionen kommen (z.B. `var dist: float = ...` statt `var dist := ...` bei `distance_to()`, `min()`, `get_node_or_null()`)
- Keine Debug-Prints im finalen Code (nur temporär zum Testen)

## Architektur
- **Stats (Model)**: Autoload, zentrale Datenhaltung aller Entity-Attribute. Basiswerte aus Resources.
- **Systeme (Controller)**: Scene-Nodes in world.tscn/dungeon.tscn, lesen/schreiben über Stats.
- **Szenen (Views)**: Rendern, Input senden, Events empfangen. Kein Gameplay-State.
- **EventBus (Signals)**: Autoload, Kommunikation zwischen Szenen und Systemen.
- **Event-Flow**: Szene → Input → EventBus → System → Stats → EventBus → Szene
- **Zwischen Szenen**: Kommunikation über EventBus. Szenen kennen sich nicht.
- **Innerhalb einer Szene**: Zugriff auf Geschwister-Nodes erlaubt.
- **Autoloads**: EventBus (Signals), Stats (Entity-Daten), GameState (Szene + Position)
- **Gruppen**: "player", "enemies", "portals", "boss", "cooldown_system"
- **Resources** für Basiswerte (Stats, Abilities), **Stats Autoload** für Laufzeitwerte

## Projektstruktur
Drei Grundordner nach Verantwortung. Resources liegen bei ihren Skripten.
- `scenes/` — Darstellung + Input
  - `player/` — Spieler + player_stats + role/ (Rollen + Abilities)
  - `enemy/` — Gegner + enemy_stats + boss/ (Boss + boss_stats)
  - `portal/` — Portal + Gate + portal_stats
  - `dungeon/` — Dungeon + dungeon_manager
  - `hud/` — HUD
  - `world/` — Hauptszene + portal_spawner
  - `effect_icon_factory.gd` — Shared Utility (Effekt-Icons)
  - `healthbar*.gd` — Healthbar-Komponenten (health, shield, status, effects)
- `systems/` — Spiellogik
  - 12 Systeme (health, shield, ability, auto_attack, cooldown, enemy_ai, respawn, spawn, effect, element, aura, buff_calc)
  - `effect.gd` — Effect Resource (Buff/Debuff/Aura Daten)
  - `aggro/` — AggroSystem (system, tracker, decay, events) + aggro_config
- `autoloads/` — Globaler Zustand
  - event_bus, game_state
  - `stats/` — stats + base_stats

## Planungsdokument
`plan.md` enthält die vollständige Projektstruktur: Szenenbaum, Szenen mit Nodes, Skripte, Components, Stats, Aggro-Regeln, Abilities und Events. Dieses Dokument ist die Wahrheit für den Soll-Zustand.

## Core Loop
1. Portale spawnen dynamisch auf der Karte (PortalSpawner, max 3, 20-40m vom Zentrum)
2. Spieler greift Portal an → Gegner spawnen bei Lebensschwellen (85%/70%/55%/40%/25%/10%)
3. Spieler bekämpft Gegner mit Abilities (Single, AOE, Utility, Ult) + Auto-Attack
4. Portal bei 0 HP → Gate spawnt, Gegner werden entfernt
5. Spieler betritt Gate → Dungeon (separate Szene, 4 Gegnergruppen + Boss)
6. Spieler kann zwischen Welt und Dungeon hin und her (beide Gates aktiv solange Boss lebt)
7. Boss stirbt → 2s Delay → Spieler wird zur Taverne teleportiert, Gates verschwinden
8. Tod → 3s Respawn bei Taverne

## Kampfsystem
- Auto-Attack: Rollenspezifisch (D: 10 Schaden/10m, T: 5 Schaden/3m, H: 1 Heilung/20m), 0.5s CD
- 5 Abilities pro Rolle: Single, AOE, Utility, Ult, Passive — jede Rolle hat eigene Werte
- GCD 0.5s (gilt für 1, 2, 4), Utility ignoriert GCD
- Heilung: Heiler heilt sich selbst (Singleplayer), is_heal Flag auf Ability
- Passive: Schadens-Boost (D), Schild-Boost (T), Heal-Boost (H) — je 50%, als Aura (50m Radius)
- Targeting: Klick, TAB (cyclet "enemies" + "portals"), Auto-Target (Gegner > Portal)
- Aggro-System: 1:1 Schaden, Tank 2x, Heilung 0.5x, verfällt -1/s, exponentiell außerhalb Portal-Radius

## Rollen
- Tank (T), Schaden (D), Heiler (H) — wechselbar mit ALT+1/2/3
- Jede Rolle hat eigenes AbilitySet mit unterschiedlichen Werten und Mechaniken
- Tank: Weniger Schaden, Nahkampf, Schild-Ult (300%), Schild-Passive
- Heiler: Heilt statt schadet (Single, AOE, Ult), Heal-Passive, AOE macht Schaden

## Effekte & Elemente
- **EffectSystem**: Verwaltet Buffs, Debuffs, Auras auf allen Entities. Kein Stacking (gleicher Name → Refresh)
- **Effect Resource**: effect_name, type (BUFF/DEBUFF/AURA), stat, value, duration (-1=permanent), is_multiplier, aura_radius, tick_interval, element
- **Auras**: Passive-Abilities werden als AURA-Effekte erstellt. Propagieren Buffs auf Spieler im aura_radius. Verlässt man Radius → Buff sofort weg
- **ElementSystem**: Verwaltet Elementar-Zustände auf Enemies + Portalen. Aktuell: Feuer (DoT 3/Tick, 2s Interval, 6s)
- **Abilities**: `element` Feld (0=NONE, 1=FIRE). Schadens-Abilities der Damage-Rolle haben element=1 (Feuer)
- **Effekt-Icons**: Auf Healthbars (Enemies, Boss, Portal) und Spieler-HUD. Aura=blau, Buff=grün, Debuff=rot

## Szenenwechsel
- Stats Autoload cached Spieler-Werte automatisch bei Szenenwechsel
- GameState speichert Rolle + Position
- Gate (Eingang): save_player → Dungeon laden
- Gate (Exit): returning_from_dungeon → Welt laden, Spieler bei Gate-Position
- Boss-Tod: dungeon_cleared → Welt laden, Cache geleert, Spieler bei Taverne mit vollen HP

## Workflow mit dem User
- **plan.md ist zentral** — User will Änderungen zuerst in plan.md dokumentiert haben, dann implementieren
- **Modularer Aufbau** — Jede Szene/Skript hat eine Aufgabe
- **Schrittweise** — Erst planen, dann Code zeigen, dann implementieren
- **Godot-Eigenheiten**: Nach Änderungen an Autoloads/Scripts Godot neu starten. Godot überschreibt .tscn beim Speichern — Szene im Editor schließen vor externen Edits.
