docs: ticket 02 (typ-registry) aufloesen, faehigkeit ins glossar, ticket 16 graduieren
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
# 02 — Typ-Registry statt Enums
|
||||
|
||||
Type: grilling
|
||||
Status: open
|
||||
Status: resolved
|
||||
Blocked by: 01
|
||||
|
||||
## Question
|
||||
@@ -19,3 +19,89 @@ Zu klären:
|
||||
- Was verliert man ohne Enum an Compile-Zeit-Sicherheit, und was fängt das ab (Validierung beim Laden)?
|
||||
|
||||
Ergebnis: das Registry-Datenmodell plus TOML-Beispiel für einen selbstdefinierten Item-Typ.
|
||||
|
||||
## Answer
|
||||
|
||||
Begriffe im [Glossar](../../../CONTEXT.md).
|
||||
|
||||
### Fünf Registries
|
||||
|
||||
**Gegenstände** · **Slots** · **Charakteroption-Kategorien** · **Charakteroptionen** · **Fähigkeiten**.
|
||||
Alle moddbar, alle namespaced.
|
||||
|
||||
### Es gibt keinen Item-Typ mehr
|
||||
|
||||
`enum ItemType` verschwindet ersatzlos — er vermischte drei Konzepte: `Helmet` ist ein *Slot*,
|
||||
`Consumable` ein *Verhalten*, `Currency` eine *Kategorie*. Genau deshalb war er nie erweiterbar.
|
||||
An seine Stelle treten drei Felder am Gegenstand: `slot` (leer = nicht ausrüstbar), `stackable`,
|
||||
`consumed_on_use`.
|
||||
|
||||
`ItemWeapon` und `ItemArmor` entfallen ebenfalls. Ein Gegenstand ist einheitlich
|
||||
`{ id, name, base_price, slot?, stackable, consumed_on_use, modifiers[], actions[], abilities[] }`.
|
||||
Ein Schwert ist ein Gegenstand mit einem Modifikator auf `damage`, ein Helm einer mit einem
|
||||
Modifikator auf `resistance`.
|
||||
|
||||
**Tragende Regel:** Braucht ein Gegenstand etwas, das Modifikator, Aktion oder Fähigkeit nicht
|
||||
ausdrücken können, ist das eine Lücke im Vokabular — sie wird dort geschlossen, nicht hier mit
|
||||
einem Sonderfeld umgangen.
|
||||
|
||||
### Fähigkeit — der dritte Begriff
|
||||
|
||||
Modifikator rechnet um, Aktion wirkt einmal, **Fähigkeit** ist ein benanntes, wiederholt auslösbares
|
||||
Angebot an den Spieler, das Aktionen ausführt. Sie erscheint im Kampfmenü, hat Symbol und Kosten,
|
||||
kann gesperrt sein. Ein Zauberspruch als Gegenstand im Inventar wäre die Alternative gewesen — dann
|
||||
könnte ein Magier seine Zaubersprüche aber verkaufen oder verlieren.
|
||||
|
||||
Dieses Ticket legt nur fest, dass Fähigkeiten eine eigene Registry sind und von Gegenständen wie
|
||||
Charakteroptionen referenziert werden. Kosten, Abklingzeit und Verfügbarkeit entscheidet Ticket 14.
|
||||
|
||||
### Deklarationen
|
||||
|
||||
```toml
|
||||
# slots.toml
|
||||
[[slots]]
|
||||
id = "core:head"
|
||||
name = "Kopf"
|
||||
order = 10
|
||||
|
||||
# character_option_categories.toml
|
||||
[[categories]]
|
||||
id = "core:race"
|
||||
name = "Rasse"
|
||||
order = 10
|
||||
pick = 1
|
||||
|
||||
# races.toml
|
||||
[[options]]
|
||||
id = "core:dwarf"
|
||||
category = "core:race"
|
||||
name = "Zwerg"
|
||||
description = "Zäh, misstrauisch, trinkfest."
|
||||
modifiers = [ { attribute = "constitution", flat = 2 } ]
|
||||
abilities = ["core:stonesense"]
|
||||
on_create = [ { action = "give_item", item = "core:pickaxe", count = 1, target = "self" } ]
|
||||
```
|
||||
|
||||
Kategorien tragen `pick = N`, damit „wähle zwei Talente" ohne neue Maschine möglich ist.
|
||||
|
||||
**`on_create` ist keine neue Mechanik**, sondern eine Liste gewöhnlicher Aktionen, einmal beim
|
||||
Charakterbau ausgeführt. Startgold, Startausrüstung und Startbuff sind damit moddbar, ohne dass die
|
||||
Engine den Begriff „Startausrüstung" kennt.
|
||||
|
||||
### Umbenennung
|
||||
|
||||
`Item.value` → `base_price` (Grundwert des Gegenstands). Attribut `shop_price` → `price_modifier`
|
||||
(Charaktereigenschaft, über die Charisma wirkt). Zwei Dinge, zwei Namen.
|
||||
|
||||
### Auflagen an andere Tickets
|
||||
|
||||
- **11 UI-Gerüst und Screen-Modell**: Charakterbogen und Charakterbau sind Schleifen über Registries,
|
||||
keine fest gemauerten Layouts — Modder können Slots *und* Wahlkategorien ergänzen.
|
||||
- **14 Kampfformeln und Rundenablauf**: muss Fähigkeitskosten, Abklingzeit und Verfügbarkeit
|
||||
mitentscheiden. Ticketkörper wurde entsprechend erweitert.
|
||||
|
||||
### Folgen für bestehenden Code
|
||||
|
||||
`src/items/weapon.rs` und `src/items/armor.rs` werden gelöscht, `enum ItemType` entfällt,
|
||||
`weapons.toml` und `armors.toml` verschmelzen zu einer gewöhnlichen Gegenstandsdatei, `items.rs`
|
||||
schrumpft auf Laden plus Registry.
|
||||
|
||||
@@ -20,6 +20,10 @@ Der Attributkatalog aus 01 liefert die Zutaten (`damage`, `hit_chance`, `critica
|
||||
- **Kritische Treffer**: Wie speist `luck` in `critical_chance`? Multipliziert `critical_factor` den
|
||||
Rohschaden oder den geminderten?
|
||||
- **Aktionen pro Zug**: Genau eine, oder gibt es Ausdauer als Budget? Wozu dient `max_stamina` sonst?
|
||||
- **Fähigkeiten** (nachgetragen aus Ticket 02): Was kostet eine Fähigkeit — Ausdauer, ein eigener
|
||||
Ressourcenpool, Ladungen? Gibt es Abklingzeiten, und werden sie in Zügen gezählt? Wann ist eine
|
||||
Fähigkeit gesperrt, und woran sieht der Spieler das? Ticket 02 hat Fähigkeiten als Registry
|
||||
festgelegt, ihre Kampfsemantik aber ausdrücklich hierher delegiert.
|
||||
- **Flucht**: Möglich, mit welcher Chance, mit welchen Kosten?
|
||||
- **Zufall**: Schadensstreuung ja oder nein, und woher kommt der Zufallsgenerator — braucht es einen
|
||||
Seed im Speicherstand?
|
||||
|
||||
27
.scratch/rustkeep-1.0/issues/16-loot-tabellen.md
Normal file
27
.scratch/rustkeep-1.0/issues/16-loot-tabellen.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# 16 — Loot-Tabellen
|
||||
|
||||
Type: grilling
|
||||
Status: open
|
||||
Blocked by: 02
|
||||
|
||||
## Question
|
||||
|
||||
Wie werden Beutefunde definiert, gewichtet und ausgewürfelt?
|
||||
|
||||
Die Gegenstands-Registry aus 02 steht, `luck` ist ein Attribut aus 01. Offen ist alles dazwischen:
|
||||
|
||||
- **Wo hängt Beute?** Am Gegner, am Raum-Prefab, an der Etage, oder an einer benannten Tabelle, die
|
||||
mehrere referenzieren können?
|
||||
- **Wie wird gewichtet?** Gewichte pro Eintrag, Wahrscheinlichkeit in Prozent, oder Seltenheitsstufen
|
||||
mit fester Verteilung? Dürfen Tabellen andere Tabellen referenzieren?
|
||||
- **Wie wirkt `luck`?** Auf die Drop-Chance, auf die Seltenheitsstufe, auf die Menge — oder auf
|
||||
mehreres, und mit welcher Formel?
|
||||
- **Mengen und Garantien**: Gibt es „genau ein Gegenstand", „null bis drei", garantierte Drops für
|
||||
Bosse? Kann ein Eintrag mehrfach gezogen werden?
|
||||
- **Etagenskalierung**: Fallen auf Etage 5 andere Gegenstände als auf Etage 1, und wird das über
|
||||
getrennte Tabellen ausgedrückt oder über eine Bedingung am Eintrag?
|
||||
- **Wie greifen Mods ein?** Nur neue Tabellen hinzufügen, oder auch Einträge in fremde Tabellen
|
||||
einhängen — und wie sieht dieses Einhängen aus, ohne die fremde Datei zu überschreiben?
|
||||
- **Zufall**: derselbe Generator wie im Kampf (Ticket 14), und gehört sein Zustand in den Speicherstand?
|
||||
|
||||
Ergebnis: Tabellenschema mit TOML-Beispiel, Gewichtungsregel, `luck`-Formel und die Mod-Einhängepunkte.
|
||||
Reference in New Issue
Block a user