4.2 KiB
02 — Typ-Registry statt Enums
Type: grilling Status: resolved Blocked by: 01
Question
Wie werden Item-Typen, Rassen und Klassen zu Daten statt zu Rust-Enums?
enum ItemType kann ein Modder nicht erweitern — es muss eine Registry aus String-IDs werden.
Zu klären:
- Was deklariert ein Typ? Ausrüstungsslot, welche Felder Pflicht sind, welche Effekte er tragen darf.
- Gibt es Slots als eigene Registry (
core:helmet), oder ist der Slot ein fester Aufzählungswert? - Wie prüft das Spiel beim Laden, dass ein Item einen existierenden Typ nennt — und was passiert, wenn nicht?
- Wie unterscheiden sich Rasse und Klasse strukturell, oder sind beide dasselbe: eine benannte Effektliste plus Metadaten?
- 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.
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
# 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.