wahnsinn
This commit is contained in:
114
module.md
Normal file
114
module.md
Normal file
@@ -0,0 +1,114 @@
|
||||
# Module — Implementierungs-Schritte zum Prototyp
|
||||
|
||||
Jedes Modul ist ein self-contained Inkrement. Nach jedem Modul ist der Prototyp spielbarer als vorher. Pro Modul: planen → zeigen → implementieren → testen.
|
||||
|
||||
## M1 — Ist-Stand-Audit ✓
|
||||
Existierender Code gegen `plan.md` abgeglichen. Ergebnis: Core-Loop zu ~60% da, aber große Abweichungen in Autoload- und System-Struktur. Siehe M1b.
|
||||
|
||||
## M1b — Architektur-Refactor
|
||||
Ist-Stand an `plan.md` angleichen, bevor neue Features gebaut werden. Jeder Sub-Schritt einzeln testen.
|
||||
|
||||
### Sub-Schritte
|
||||
1. **Zentraler `stats.gd` Autoload**
|
||||
- Neue Datei `autoloads/stats.gd` mit API: `register(entity, resource)`, `get(entity, stat_name)`, `set(entity, stat_name, value)`, `deregister(entity)`
|
||||
- Hält Dictionary[Node, Dictionary] für Laufzeit-Werte aller Entities
|
||||
- Migration: player_stats.gd, enemy_stats.gd, boss_stats.gd, portal_stats.gd → alle Lese-/Schreib-Stellen auf zentrales `Stats` umstellen
|
||||
- Entity-Registrierungs-Pattern: `_ready() → Stats.register(self, stats_resource)`, `_exit_tree() → Stats.deregister(self)`
|
||||
- player_cache (für Szenenwechsel) in Stats
|
||||
|
||||
2. **`game_state.gd` Autoload**
|
||||
- Neue Datei `autoloads/game_state.gd`
|
||||
- Speichert: current_role, player_position, current_wave (später)
|
||||
- Wird von Szenen gelesen beim Laden
|
||||
|
||||
3. **Systeme → Szenen-Skripte umziehen**
|
||||
- `systems/role_system.gd` entfernen, Logik nach `scenes/player/role/role.gd` (prüfen: schon da?)
|
||||
- `systems/targeting_system.gd` entfernen, Logik nach `scenes/player/targeting.gd`
|
||||
- `systems/hud_system.gd` entfernen, Logik in `scenes/hud/hud_*.gd` (vitals, respawn, abilities, effects)
|
||||
- `systems/nameplate_system.gd` entfernen, in Enemy-Szene integrieren
|
||||
- `systems/portal_system.gd` entfernen, Logik in `scenes/portal/init.gd` / `portal.gd`
|
||||
- `systems/dungeon_system.gd` entfernen, Logik in `scenes/dungeon/dungeon_manager.gd`
|
||||
- Alle Signal-Verdrahtungen anpassen
|
||||
|
||||
4. **Effect-Hierarchie aufräumen**
|
||||
- `buff_system.gd` + `debuff_system.gd` → Children von `effect_system.gd`
|
||||
- Neuer `buff_calc_system.gd` als Child von `effect_system.gd` (aggregiert Multiplier → Stats/Shield)
|
||||
|
||||
5. **`attack_system.gd` vs `ability_system.gd`**
|
||||
- Rollen klären: Ability-Trigger + Schaden-Applikation
|
||||
- Wahrscheinlich: `attack_system.gd` = AutoAttack-Loop (_process-driven), `ability_system.gd` = Ability-Execution bei Input
|
||||
- Falls Duplikat: mergen. Falls getrennt: umbenennen zu `auto_attack_system.gd` wie plan.md
|
||||
|
||||
6. **Core-Loop-Test nach Refactor**
|
||||
- Godot starten, Portal angreifen, Dungeon betreten, Boss besiegen, zur Taverne zurück
|
||||
- Rollen-Wechsel testen, alle Abilities, Respawn, Effekte
|
||||
- Keine Regressions
|
||||
|
||||
7. **`plan.md` finalisieren**
|
||||
- Ungenaue Referenzen (`combat.gd`, `combat_state.gd`, `enemy_movement.gd`) durch Ist-Skripte ersetzen
|
||||
- System-Liste auf tatsächliche Anzahl anpassen
|
||||
- Autoload-Sektion final
|
||||
|
||||
## M2 — Startmenü
|
||||
- `scenes/menu/main_menu.tscn` — Buttons: Singleplayer, Host, Join, Quit
|
||||
- Singleplayer → `world.tscn`; Host/Join zunächst disabled (bis M11)
|
||||
- `project.godot`: main_scene = main_menu
|
||||
|
||||
## M3 — Taverne als Entity mit HP
|
||||
- `TavernStats` Resource (nur `max_health`)
|
||||
- Taverne-Node: `HitArea` (Area3D), `Healthbar`, registriert bei Stats
|
||||
- HUD: Tavern-HP oben mittig
|
||||
- Taverne HP = 10 × normales Portal HP
|
||||
|
||||
## M4 — WaveSystem (Basis)
|
||||
- `wave_system.gd`: Timer (1h), Wellen-Counter
|
||||
- PortalSpawner refactoren: immer max 3 normale (sofort nachspawnen)
|
||||
- HUD: Wellen-Nummer + Restzeit oben
|
||||
|
||||
## M5 — Rotes Portal
|
||||
- `PortalStats.variant` = NORMAL | RED
|
||||
- Rotes Portal: 10× HP, rote Mesh, Gruppe `red_portal`
|
||||
- WaveSystem spawnt 1 rotes pro Welle, nach Besieg → nächste Welle + neues rotes
|
||||
- Dungeon-Gegner des roten Portals: 10× stärker
|
||||
|
||||
## M6 — XP + Level-System
|
||||
- `PlayerStats`: `level, xp, xp_to_next`
|
||||
- `xp_system.gd`: XP bei Dungeon-Clear (1 normal, 10 rot)
|
||||
- Fibonacci-Level-Kurve
|
||||
- Level-Up: alle PlayerStats × 2, aktuelle HP/Schild auf neues Max
|
||||
- HUD: XP-Balken + Level-Label
|
||||
|
||||
## M7 — Gegner-Skalierung
|
||||
- EnemyStats × 2^(player_level−1) bei Spawn
|
||||
- Rotes Portal: zusätzlich × 10
|
||||
|
||||
## M8 — InvasionSystem + Game-Over
|
||||
- Timer-Ablauf ohne rotes Portal besiegt: InvasionSystem aktiviert
|
||||
- Alle noch lebenden Gegner des roten Portals brechen aus, spawnen am Rand, laufen zur Taverne
|
||||
- Schaden an Taverne über HealthSystem
|
||||
- Alle tot → `invasion_ended(true)` → nächste Welle + neues rotes
|
||||
- Taverne HP 0 → `tavern_destroyed` → Game-Over-Overlay → 3s Delay → Reset: Level 1, Welle 1, Stats Base, zurück ins Startmenü oder neuer Run
|
||||
|
||||
## M9 — Modelle + Animationen
|
||||
- Einfache 3D-Modelle (Mixamo / Kenney / KayKit) für Spieler, Gegner, Boss, Portal, Taverne
|
||||
- Animationen: Idle, Walk, Attack, Death
|
||||
- Simple Shader (unlit oder lite-PBR mit Emissive für Portale)
|
||||
|
||||
## M10 — Audio
|
||||
- Musik: Taverne (ruhig), Kampf, Invasion (bedrohlich)
|
||||
- SFX: Ability-Cast, Hit, Death, Portal-Spawn, Level-Up, Invasion-Alarm, Taverne-Schaden
|
||||
- Quellen: frei zugängliche CC0-Packs (freesound, OpenGameArt) — wird pro Sound dokumentiert
|
||||
|
||||
## M11 — Multiplayer P2P
|
||||
- `ENetMultiplayerPeer` — Host öffnet Port, Client joint via IP
|
||||
- `MultiplayerSpawner` für Spieler + Gegner
|
||||
- `MultiplayerSynchronizer` für Stats-Felder
|
||||
- Authoritative Host: Wave/Invasion/Taverne-State liegt beim Host
|
||||
- Shared World (1 Taverne, alle Spieler verteidigen gemeinsam)
|
||||
- Startmenü: Host/Join aktivieren
|
||||
|
||||
## Reihenfolge-Begründung
|
||||
- M1 klärt Ist-Stand (verhindert doppelte Arbeit)
|
||||
- M2–M8 bringen den Run-Loop zum Laufen (Kernspiel komplett spielbar)
|
||||
- M9–M10 machen es „erlebbar" (Look + Feel)
|
||||
- M11 als Letztes — größter Brocken, baut auf stabilem Core auf
|
||||
Reference in New Issue
Block a user