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

Zwischen Szenen: Kommunikation über EventBus (Autoload). Szenen kennen sich nicht.
Innerhalb einer Szene: Modulare Skripte als Child-Nodes, Zugriff auf Geschwister-Nodes erlaubt.
Gruppen: "player", "enemies", "portals"
Resources für statische Konfiguration (Stats, Abilities), Nodes für laufenden Zustand
Portale sind keine Gegner — eigene Gruppe "portals", kein State/Aggro/Combat

Projektstruktur

scenes/ — .tscn Dateien (world, player, enemy, portal, hud)
scripts/player/ — Spieler-Skripte (player, camera, movement, combat, targeting, role, respawn)
scripts/enemy/ — Gegner-Skripte (enemy, enemy_movement, enemy_combat, enemy_aggro)
scripts/portal/ — Portal-Skripte (portal)
scripts/components/ — Wiederverwendbare Komponenten (health, shield, healthbar, spawner)
scripts/abilities/ — Ability-System (ability, ability_set)
scripts/resources/ — Resource-Klassen (entity_stats)
resources/stats/ — Stats .tres (player_stats, enemy_stats, portal_stats)
resources/abilities/ — Ability .tres (single_attack, aoe_attack, utility_shield_reset, ult_burst, passive_damage_boost)
resources/ability_sets/ — AbilitySet .tres pro Rolle (tank_set, damage_set, healer_set)

Planungsdokument

mmo/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/ 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

Portal spawnt auf der Karte
Spieler greift Portal an → Gegner spawnen bei Lebensschwellen (85%/70%/55%/40%/25%/10%)
Spieler bekämpft Gegner mit Abilities (Single, AOE, Utility, Ult) + Auto-Attack
Portal bei 0 HP → Phase 2 (geplant: wird Gate zu Dungeon)
Tod → 3s Respawn am Startpunkt

Kampfsystem

Auto-Attack: 10 Schaden, 1s, automatisch bei anvisiertem Gegner im Kampf
5 Abilities pro Rolle: Single, AOE, Utility, Ult, Passive
GCD 0.5s (gilt für 1, 2, 4), Utility ignoriert GCD
Cooldown-Overlay in AbilityBar (von oben nach unten)
Targeting: Klick, TAB (cyclet "enemies" + "portals"), Auto-Target (Gegner > Portal)
Aggro-System: 1:1 Schaden, Tank 2x, verfällt -1/s, exponentiell außerhalb Portal-Radius

Rollen

Tank (T), Schaden (D), Heiler (H) — wechselbar mit ALT+1/2/3
Aktuell alle gleiche Abilities, später unterschiedlich
Jede Rolle hat eigenes AbilitySet (Resource)

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.

3.8 KiB Raw Blame History