# 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
- **Systeme berechnen und entscheiden**, Szenen rendern und senden/empfangen
- **Event-Flow**: Input → Intention-Event → System → Ergebnis-Event → Node
- **Systeme** sind Scene-Nodes (nicht Autoloads), gefunden über Gruppen
- **Zwischen Szenen**: Kommunikation über EventBus (Autoload). Szenen kennen sich nicht.
- **Innerhalb einer Szene**: Modulare Skripte als Child-Nodes, Zugriff auf Geschwister-Nodes erlaubt.
- **Autoloads**: EventBus (Signals), GameState (Spielerzustand zwischen Szenenwechseln)
- **Gruppen**: "player", "enemies", "portals", "boss"
- **Resources** für statische Konfiguration (Stats, Abilities), **Nodes** für laufenden Zustand

## Projektstruktur
- `scenes/` — .tscn Dateien
  - `world.tscn` — Hauptszene (100x100m, Taverne in Mitte)
  - `player/player.tscn` — Spieler
  - `enemy/enemy.tscn` — Gegner
  - `enemy/boss.tscn` — Boss (eigene Szene, erbt von Enemy)
  - `portal/portal.tscn` — Portal (Gegner-Spawner)
  - `portal/gate.tscn` — Gate (Teleporter, konfigurierbar: Dungeon-Eingang oder Exit)
  - `dungeon/dungeon.tscn` — Dungeon (15x90m Schlauch, 4 Gegnergruppen + Boss)
  - `hud/hud.tscn` — HUD
- `scripts/systems/` — Zentrale Systeme (health, shield, respawn, ability, cooldown, damage, buff, aggro, enemy_ai, spawn)
- `scripts/player/` — Spieler-Skripte (player, camera, movement, combat, targeting, role, hud)
- `scripts/enemy/` — Gegner-Skripte (enemy, enemy_movement, boss)
- `scripts/portal/` — Portal + Gate (portal, gate)
- `scripts/dungeon/` — Dungeon-Logik (dungeon_manager)
- `scripts/components/` — Wiederverwendbare Komponenten (health, shield, healthbar)
- `scripts/abilities/` — Ability-System (ability, ability_set)
- `scripts/resources/` — Resource-Klassen (entity_stats)
- `scripts/event_bus.gd` — Globale Signals
- `scripts/game_state.gd` — Spielerzustand zwischen Szenenwechseln
- `resources/stats/` — Stats .tres (player_stats, enemy_stats, portal_stats, boss_stats)
- `resources/abilities/` — Ability .tres pro Rolle (single_attack, tank_single, healer_single, etc.)
- `resources/ability_sets/` — AbilitySet .tres pro Rolle (tank_set, damage_set, healer_set)

## 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.

## Design-Dokumente
Unter `~/Documents/2026/projekte/mmo/infosammlung/` liegen die originalen Design-Docs:
- `story.md` — Gameplay-Loop, Szenarien, Steuerung
- `idden.md` — Alle Ideen, Kernphilosophie, Technik
- `Szenarien.md` — Ressourcenanfragen, Dungeons, Gemeinschaft, Endgame
- `Level 1.md` bis `Level 3.md` — Systeme nach Priorität

## 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%
- 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

## Szenenwechsel
- GameState Autoload speichert Spielerzustand (HP, Shield, Rolle) zwischen Szenen
- Gate (Eingang): save_player → Dungeon laden
- Gate (Exit): save_player, returning_from_dungeon → Welt laden, Spieler bei Gate-Position
- Boss-Tod: dungeon_cleared → Welt laden, Spieler bei Taverne, Gates weg
- PortalSpawner stellt Gate wieder her wenn portal_position gesetzt und Boss noch lebt

## 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.