mmo/CLAUDE.md

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

• scenes/ — .tscn Dateien
  • world.tscn — Hauptszene (100x100m, Taverne, 10 Systeme)
  • player/player.tscn — Spieler
  • enemy/enemy.tscn — Gegner
  • enemy/boss.tscn — Boss
  • portal/portal.tscn — Portal
  • portal/gate.tscn — Gate (Teleporter)
  • dungeon/dungeon.tscn — Dungeon (15x90m, 10 Systeme)
  • hud/hud.tscn — HUD
• scripts/systems/ — 10 Systeme (health, shield, damage, ability, cooldown, aggro, enemy_ai, respawn, spawn, buff)
• 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/ — Healthbar (healthbar)
• scripts/abilities/ — Ability-Daten (ability, ability_set)
• scripts/resources/ — Resource-Klassen (base_stats, player_stats, enemy_stats, boss_stats, portal_stats)
• scripts/event_bus.gd — Globale Signals
• scripts/stats.gd — Zentrale Entity-Datenhaltung
• scripts/game_state.gd — Szene + Position zwischen Szenenwechseln
• scripts/world/portal_spawner.gd — Portal-Spawning
• resources/stats/ — Stats .tres (player_stats, enemy_stats, portal_stats, boss_stats)
• resources/abilities/ — Ability .tres pro Rolle
• 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

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