88 lines
5.3 KiB
Markdown
88 lines
5.3 KiB
Markdown
# 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
|
|
- `player/` — Spieler (.tscn + .gd): player, camera, movement, combat, targeting, role
|
|
- `enemy/` — Gegner (.tscn + .gd): enemy, enemy_movement, boss
|
|
- `portal/` — Portal + Gate (.tscn + .gd): portal, gate
|
|
- `dungeon/` — Dungeon (.tscn + .gd): dungeon, dungeon_manager
|
|
- `hud/` — HUD (.tscn + .gd): hud
|
|
- `world/` — Hauptszene (.tscn + .gd): world, portal_spawner
|
|
- `systems/` — 10 Systeme: health, shield, damage, ability, cooldown, aggro, enemy_ai, respawn, spawn, buff
|
|
- `autoload/` — EventBus (event_bus), Stats (stats), GameState (game_state)
|
|
- `components/` — Shared Components: healthbar
|
|
- `resources/stats/` — Stats-Klassen (.gd) + Daten (.tres): base_stats, player_stats, enemy_stats, boss_stats, portal_stats
|
|
- `resources/roles/` — Ability/AbilitySet-Klassen (.gd) + pro Rolle (damage, tank, healer):
|
|
- `{rolle}/set.tres` — AbilitySet der Rolle
|
|
- `{rolle}/abilities/` — Abilities (single, aoe, utility, ult, passive)
|
|
|
|
## 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.
|