Files
rustkeep/.scratch/rustkeep-1.0/map.md

6.2 KiB

Map: rustkeep 1.0

Gitea-Spiegel: Issue #1. Diese Datei ist die kanonische Quelle — bei Abweichung gilt .scratch/.

Gitea hat keine nativen Parent-Child- oder Blocking-Beziehungen, deshalb steht beides dort als Konvention im Body. Zuordnung Ticket → Gitea-Issue:

Ticket Gitea Ticket Gitea
01 Effekt-Vokabular #2 06 Research ratatui #7
02 Typ-Registry #3 07 Game-State-Baum #8
03 Mod-Ladepipeline #4 08 Event-System #9
04 Fehlerstrategie #5 09 Save-Schema #10
05 Research Script-Engine #6 10 Raum-Prefab-Format #11
11 UI-Gerüst #12 12 Prototyp ratatui #13
13 Script-Engine wählen #14

Destination

Alle Architektur- und Design-Entscheidungen für rustkeep 1.0 sind getroffen — nicht gebaut, entschieden. 1.0 heißt: 5 Etagen mit Boss, Solo-Held mit Rasse und Klasse, Grid-Erkundung mit Menü-Kampf, Inventar und Ausrüstung, Quests, NPCs, Handel, Speichern/Laden, Mod-Support auf drei Stufen.

Notes

Domain: Rust-Terminal-Roguelike, moddbar. Repo: MDietermann/rustkeep.

Jede Session konsultiert: ponytail (dauerhaft aktiv), /grilling und /domain-modeling für Grilling-Tickets, /research für Research-Tickets, /prototype für Prototype-Tickets.

Feststehende Rahmenentscheidungen aus der Charter-Session:

Thema Entscheidung
Motivation Rust lernen und Spiel bauen — Lern-Entscheidungen bekommen eigene Tickets, wo sie echte Architekturfragen sind
Kernschleife Grid-Bewegung zum Erkunden, Kampf im Menü (Dungeon Master / Etrian Odyssey)
Held Solo, kein Party-System
Rendering ratatui + crossterm; print_box fliegt raus, sobald ratatui steht
Etagen Hybrid — Raum-Prefabs in TOML, prozedural zusammengesetzt
Daten Alles TOML, zur Laufzeit geladen. include_str! und enum ItemType fallen
Mod-IDs Namespaced (core:iron_sword), Ladereihenfolge aus Mod-Manifest. Das Kernspiel ist selbst ein Mod
Mod-Stufen Daten → Typen → Scripting, in dieser Reihenfolge. Scripting setzt auf der Typ-Registry auf
Effekte Ein generisches Effekt-System mit Wirkung auf Stats. Rasse, Klasse, Items, Statuseffekte, Quest-Belohnungen und später Scripts nutzen dasselbe Vokabular — dieses Vokabular ist die Mod-API
Quests Bedingung + Belohnung als Daten, generisches Event-/Trigger-System
Weltzustand Game-Ownership-Baum, Verweise über IDs/Indizes. Kein ECS
Fehler Result statt panic! — kaputte Mod-TOMLs sind der Normalfall, nicht der Ausnahmefall
Save TOML, Mod-Liste im Header, fehlender Mod = Warnung und Verwerfen, kein harter Abbruch

Leitplanke aus Ticket 05: Scripts reden ausschließlich über das Effekt-Vokabular, nie direkt mit dem Game-State. Solange das gilt, ist die Script-Engine austauschbar — Ticket 01 entscheidet damit indirekt auch über Ticket 13.

Decisions so far

  • 05 — Research: Script-Engine (#6) — Empfehlung Rhai wegen Fehlermeldungen mit Zeile und Spalte, billiger Typ-Brücke, AST-Hot-Reload und Build ohne cc. Gemessen: mlua liest unter StdLib::ALL_SAFE per io.open echte Dateien — „safe" heißt dort speichersicher, nicht fähigkeitsbeschränkt. Lua gewinnt bei der Modder-Vertrautheit; WASM scheidet für 1.0 aus. Kernfolge: reden Scripts nur über das Effekt-Vokabular, ist die Engine-Wahl umkehrbar. Entscheidung offen in Ticket 13.
  • 06 — Research: ratatui-App-Architektur (#7) — Screen-Stack über zentralem Game-State statt Elm oder Component-Trait; game/ bleibt ratatui-frei; Popups per Clear auf Sub-Rect statt Widget-Stack; blockierendes event::read() ohne Tick; Dungeon-Grid ist Eigenbau, es gibt kein Widget dafür; ratatui 0.30.2 mit MSRV 1.88; KeyEventKind::Press-Filter unter Windows Pflicht. Voller Bericht in research/06.

Not yet specified

  • Kampfmechanik im Detail — Initiative, Aktionen pro Runde, Trefferformel, Krit, Flucht. Wartet auf das Effekt-Vokabular (01), weil Angriffe und Fähigkeiten Effekte sind.
  • Loot-Tabellen — wie Drops definiert und gewichtet werden, wie luck einwirkt. Wartet auf die Typ-Registry (02).
  • XP-Kurve und Progression — was Level-ups geben, wie Rasse/Klasse mitskalieren. Wartet auf 01.
  • Boss-Design — ob Bosse nur Gegner mit besseren Werten sind oder eigene Mechanik brauchen (Phasen, Skripte). Berührt Stufe (c) des Mod-Supports.
  • NPC- und Handelsmodell — Warenbestand, Preisbildung über charisma, Dialogdaten. Wartet auf das Event-System (08).
  • Inventar-UX — Slots, Gewicht oder Kapazität, Sortierung, Vergleichsansicht. Wartet jetzt auf das Screen-Modell (11), nicht mehr auf 06.
  • Mod-Verteilung — wie Spieler an Mods kommen und ob es eine Versionsprüfung gibt. Wartet auf das Manifest-Format (03).

Out of scope

  • Story-Modul — kommt später als eigenes Modul, linear statt prozedural, ebenfalls moddbar. Eigene Map, wenn 1.0 steht.
  • Party-System — bewusst gegen Solo entschieden; ein Wechsel wäre ein Umbau der Kampfarchitektur, keine Erweiterung.
  • Multiplayer
  • Grafik jenseits des Terminals