From b92aecb71adc53128a2b9f205130b6e0972f8888 Mon Sep 17 00:00:00 2001 From: Bastian Wagner Date: Thu, 20 Aug 2026 10:16:51 +0200 Subject: [PATCH] renaming --- .... 2026, 21_29_37 (5).png => drop-card.png} | Bin ..., 21_29_37 (6).png => highlight-frame.png} | Bin ...ug. 2026, 21_29_37 (3).png => list-bg.png} | Bin ...g. 2026, 21_29_37 (1).png => panel-bg.png} | Bin ...6, 21_29_37 (2).png => sidepanel-left.png} | Bin ...026, 21_29_37 (8).png => statusbar-bg.png} | Bin ... Monster Loot Categories Specification V1.md | 1471 +++++++++++++++++ 7 files changed, 1471 insertions(+) rename apps/web/public/assets/hud-elements/{ChatGPT Image 19. Aug. 2026, 21_29_37 (5).png => drop-card.png} (100%) rename apps/web/public/assets/hud-elements/{ChatGPT Image 19. Aug. 2026, 21_29_37 (6).png => highlight-frame.png} (100%) rename apps/web/public/assets/hud-elements/{ChatGPT Image 19. Aug. 2026, 21_29_37 (3).png => list-bg.png} (100%) rename apps/web/public/assets/hud-elements/{ChatGPT Image 19. Aug. 2026, 21_29_37 (1).png => panel-bg.png} (100%) rename apps/web/public/assets/hud-elements/{ChatGPT Image 19. Aug. 2026, 21_29_37 (2).png => sidepanel-left.png} (100%) rename apps/web/public/assets/hud-elements/{ChatGPT Image 19. Aug. 2026, 21_29_37 (8).png => statusbar-bg.png} (100%) create mode 100644 docs/superpowers/specs/Ashen Realms – Loot Bags & Monster Loot Categories Specification V1.md diff --git a/apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (5).png b/apps/web/public/assets/hud-elements/drop-card.png similarity index 100% rename from apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (5).png rename to apps/web/public/assets/hud-elements/drop-card.png diff --git a/apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (6).png b/apps/web/public/assets/hud-elements/highlight-frame.png similarity index 100% rename from apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (6).png rename to apps/web/public/assets/hud-elements/highlight-frame.png diff --git a/apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (3).png b/apps/web/public/assets/hud-elements/list-bg.png similarity index 100% rename from apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (3).png rename to apps/web/public/assets/hud-elements/list-bg.png diff --git a/apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (1).png b/apps/web/public/assets/hud-elements/panel-bg.png similarity index 100% rename from apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (1).png rename to apps/web/public/assets/hud-elements/panel-bg.png diff --git a/apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (2).png b/apps/web/public/assets/hud-elements/sidepanel-left.png similarity index 100% rename from apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (2).png rename to apps/web/public/assets/hud-elements/sidepanel-left.png diff --git a/apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (8).png b/apps/web/public/assets/hud-elements/statusbar-bg.png similarity index 100% rename from apps/web/public/assets/hud-elements/ChatGPT Image 19. Aug. 2026, 21_29_37 (8).png rename to apps/web/public/assets/hud-elements/statusbar-bg.png diff --git a/docs/superpowers/specs/Ashen Realms – Loot Bags & Monster Loot Categories Specification V1.md b/docs/superpowers/specs/Ashen Realms – Loot Bags & Monster Loot Categories Specification V1.md new file mode 100644 index 0000000..0686678 --- /dev/null +++ b/docs/superpowers/specs/Ashen Realms – Loot Bags & Monster Loot Categories Specification V1.md @@ -0,0 +1,1471 @@ +# Ashen Realms – Loot Bags & Monster Loot Categories Specification V1 + +## Zweck dieser Dokumentation + +Dieses Dokument definiert das **Taschen- und Beutekategoriesystem** von Ashen Realms. + +Das System ergänzt: + +- Monster +- Loot +- Inventar +- Händler +- Ruf +- Expeditionen +- spätere Crafting-Systeme + +Die zentrale Idee lautet: + +> Gegner hinterlassen thematisch passende Beute. Diese Beute wird nicht unbegrenzt im normalen Inventar getragen, sondern benötigt passende spezialisierte Taschen. + +Dadurch entsteht ein natürlicher Expeditionsrhythmus: + +**Gebiet verlassen → Gegner bekämpfen → Beutetaschen füllen → zurückkehren → Beute verwerten → erneut aufbrechen** + +Das System soll keine klassische Gewichtssimulation darstellen. + +Es soll leicht verständliche, sichtbare und langfristig verbesserbare Kapazitätsgrenzen erzeugen. + +--- + +# 1. Grundprinzip + +Ashen Realms unterscheidet zwischen mehreren Arten transportierbarer Gegenstände. + +## Normales Inventar + +Enthält insbesondere: + +- Waffen +- Rüstung +- Amulette +- normale Verbrauchsgegenstände +- besondere Gegenstände +- nicht kategorisierte Items + +Das normale Inventar bleibt weiterhin slotbasiert. + +--- + +## Kampftasche + +Die bereits bestehende Kampftasche bleibt ein separates System. + +Sie bestimmt, welche Verbrauchsgegenstände während eines Kampfes verwendet werden können. + +Beispiele: + +- Heiltränke +- Gegengifte +- spätere Kampfverbrauchsgegenstände + +Die Kampftasche besitzt keine Verbindung zu normalen Beutetaschen. + +--- + +## Questinventar + +Questgegenstände belegen grundsätzlich keine Kapazität einer normalen Beutetasche. + +Beispiele: + +- Briefe +- Schlüssel +- Questrelikte +- Beweisstücke +- Storygegenstände + +Questfortschritt darf nicht blockiert werden, weil eine Beutetasche voll ist. + +--- + +## Beutetaschen + +Bestimmte Materialien und Handelswaren benötigen eine passende Beutetasche. + +Beispiele: + +- Felle +- Klauen +- Zähne +- Plünderergut +- Münzen +- Relikte + +Jede Tasche unterstützt genau eine definierte **Loot Category** oder eine explizite Gruppe kompatibler Kategorien. + +--- + +# 2. Designziele + +Das Taschensystem besitzt folgende Ziele: + +1. Expeditionen sollen eine natürliche Länge erhalten. +2. Rückkehr zu Händlern und sicheren Orten soll spielerisch sinnvoll sein. +3. Taschen sollen selbst Teil der Progression sein. +4. Unterschiedliche Gegnerarten sollen unterschiedliche wirtschaftliche Identitäten erhalten. +5. Beute soll thematisch zum Gegner passen. +6. Größere Taschen sollen spürbaren Komfort und Fortschritt erzeugen. +7. Das System darf keine komplizierte Gewichtssimulation erzeugen. +8. Neue Gegner und Materialien sollen datengetrieben ergänzt werden können. + +--- + +# 3. Kein Gewichtssystem + +Beutetaschen besitzen ausschließlich eine diskrete Kapazität. + +Beispiel: + +**Einfacher Fellbeutel** + +Kapazität: + +`5` + +Bedeutung: + +Der Spieler kann insgesamt fünf Einheiten kompatibler Fell-Beute tragen. + +Es existiert keine Berechnung wie: + +`Wolfspelz = 2,4 kg` + +oder: + +`Maximales Gewicht = 32 kg` + +Alle kompatiblen Gegenstände verbrauchen standardmäßig: + +**1 Kapazität pro Einheit** + +Spätere Sondergegenstände dürfen bei Bedarf einen abweichenden Kapazitätsverbrauch besitzen. + +Für V1 ist dies nicht notwendig. + +--- + +# 4. Loot Categories + +Alle Materialien oder Handelswaren, die das Taschensystem verwenden, besitzen eine definierte Loot Category. + +V1 verwendet zunächst wenige breite Kategorien. + +## HIDE + +Tierhäute und Felle. + +Beispiele: + +- Aschenfell +- Zähes Fell +- Dämmerfell +- Schwarzmähnenfell +- Hirschhaut + +Passende Tasche: + +**Fellbeutel** + +--- + +## TROPHY + +Kleine Jagdtrophäen und hochwertige Bestienteile. + +Beispiele: + +- Zahn +- Klaue +- Horn +- Giftdrüse +- Bestienherz + +Passende Tasche: + +**Jagdtasche** + +--- + +## HUMANOID_SPOILS + +Beute von humanoiden Gegnern. + +Beispiele: + +- Plündererabzeichen +- Stoffreste +- gestohlene Handelsware +- Waffenfragmente +- militärische Insignien + +Passende Tasche: + +**Plünderbeutel** + +--- + +## COIN + +Münzen und ähnliche kleine Wertgegenstände. + +Wichtig: + +Diese Kategorie bezeichnet nicht die globale Charakterwährung Silber. + +Sie enthält physische Beutegegenstände wie: + +- alte Münzen +- fremde Münzen +- Münzrollen +- wertvolle Token +- gestohlene Münzbeutel + +Passende Tasche: + +**Münztasche** + +Diese Gegenstände können später bei passenden Händlern gegen reguläres Silber oder Ruf eingetauscht werden. + +--- + +## RELIC + +Archäologische, magische und untote Beute. + +Beispiele: + +- Knochenfragment +- Siegelbruch +- Grabbeigabe +- Reliktfragment +- verdorbene Reliquie + +Passende Tasche: + +**Reliquienbehälter** + +--- + +# 5. Erweiterbare Kategorien + +Das System muss so aufgebaut sein, dass später weitere Kategorien ergänzt werden können. + +Mögliche spätere Kategorien: + +- HERB +- ORE +- GEM +- FISH +- ALCHEMY +- ARCANE +- DEMONIC +- INSECT +- FOOD + +Diese Kategorien sind nicht Bestandteil von V1. + +Neue Kategorien dürfen erst hinzugefügt werden, wenn entsprechender Content tatsächlich existiert. + +--- + +# 6. Monster Categories + +Monster erhalten zusätzlich eine oder mehrere **Monster Categories**. + +Monster Categories beschreiben, welcher übergeordneten Gegnerart ein Gegner angehört. + +V1 sollte mindestens folgende Kategorien unterstützen: + +- BEAST +- HUMANOID +- UNDEAD +- INSECT +- ABERRATION + +Optional später: + +- CONSTRUCT +- DEMON +- ELEMENTAL +- DRAGON +- SPIRIT + +--- + +# 7. Zweck der Monster Categories + +Monster Categories dienen nicht direkt als Taschenzuordnung. + +Sie besitzen mehrere mögliche Funktionen: + +- Standard-Loot festlegen +- Loot-Tabellen organisieren +- Quests filtern +- Händleraufträge definieren +- Fähigkeiten gegen bestimmte Gegnertypen ermöglichen +- Sets oder Items mit Boni gegen Gegnertypen unterstützen +- Statistiken und Bestiarium ermöglichen + +Beispiel: + +**Aschenratte** + +Monster Category: + +`BEAST` + +Typischer Loot: + +`HIDE` + +--- + +**Straßenräuber** + +Monster Category: + +`HUMANOID` + +Typischer Loot: + +`HUMANOID_SPOILS` + +--- + +**Giftspinne** + +Monster Category: + +`INSECT` + +Typischer Loot: + +`TROPHY` + +--- + +**Knochenritter** + +Monster Category: + +`UNDEAD` + +Typischer Loot: + +`RELIC` + +--- + +# 8. Monster Category und Loot Category bleiben getrennt + +Diese beiden Systeme dürfen technisch nicht identisch sein. + +Beispiel: + +Ein Wolf ist: + +`MonsterCategory.BEAST` + +Er kann aber gleichzeitig droppen: + +- Fell → `HIDE` +- Zahn → `TROPHY` + +Ein Straßenräuber ist: + +`MonsterCategory.HUMANOID` + +Er kann droppen: + +- Abzeichen → `HUMANOID_SPOILS` +- gestohlene Münzen → `COIN` + +Dadurch bleibt das System flexibel. + +Grundsatz: + +> Monster Category beschreibt den Gegner. Loot Category beschreibt den Gegenstand. + +--- + +# 9. ItemDefinition-Erweiterung + +Materialien und Handelsgegenstände benötigen künftig eine optionale Loot Category. + +Konzeptionell: + +```ts +ItemDefinition { + ... + itemType + lootCategory? +} +``` + +Beispiel: + +```ts +{ + key: 'ash-hide', + name: 'Aschenfell', + itemType: 'TRADE_GOOD', + lootCategory: 'HIDE' +} +``` + +Equipment besitzt keine Loot Category. + +Beispiel: + +```ts +{ + key: 'bandit-blade', + name: 'Räuberklinge', + itemType: 'EQUIPMENT', + lootCategory: null +} +``` + +Eine Räuberklinge landet weiterhin im normalen Inventar. + +--- + +# 10. MonsterDefinition-Erweiterung + +MonsterDefinition erhält mindestens: + +```ts +monsterCategories: MonsterCategory[] +``` + +V1 kann technisch auch genau eine Hauptkategorie verwenden. + +Das Modell sollte jedoch eine spätere Mehrfachzuordnung nicht unnötig verhindern. + +Beispiel: + +```ts +{ + key: 'ash-rat', + name: 'Aschenratte', + monsterCategories: ['BEAST'] +} +``` + +Später könnte ein Gegner beispielsweise sein: + +```ts +['UNDEAD', 'BEAST'] +``` + +--- + +# 11. Loot bleibt über Loot Tables definiert + +Monster Categories erzeugen nicht automatisch sämtliche Drops. + +Die existierenden Loot Tables bleiben die verbindliche Quelle dafür, was ein konkreter Gegner hinterlassen kann. + +Beispiel: + +```text +Aschenratte +→ 70 % Aschenfell +→ 15 % Rattenzahn +→ 5 % besonderes Item +``` + +Die Monster Category kann jedoch genutzt werden, um: + +- Default-Regeln +- Content-Validierung +- Editor-Vorschläge +- Questfilter + +zu unterstützen. + +Grundsatz: + +> Monster Categories unterstützen Loot-Definitionen. Sie ersetzen keine individuellen Loot Tables. + +--- + +# 12. BagDefinition + +Taschen sollten als datengetriebene Definitionen existieren. + +Konzeptionell: + +```ts +BagDefinition { + id + key + name + description + supportedLootCategories + capacity + tier + iconPath +} +``` + +Beispiel: + +```ts +{ + key: 'simple-hide-pouch', + name: 'Einfacher Fellbeutel', + supportedLootCategories: ['HIDE'], + capacity: 5, + tier: 1 +} +``` + +--- + +# 13. CharacterBag + +Ein Charakter besitzt konkrete freigeschaltete oder ausgerüstete Taschen. + +Konzeptionell: + +```ts +CharacterBag { + id + characterId + bagDefinitionId + equipped +} +``` + +Die tatsächliche Beute bleibt als CharacterItem beziehungsweise entsprechender Player-State gespeichert. + +Die Tasche bestimmt lediglich, wie viel davon gleichzeitig getragen werden darf. + +--- + +# 14. V1-Ausrüstungsmodell für Taschen + +Für V1 wird ein möglichst einfaches Modell empfohlen. + +Der Spieler besitzt pro Loot Category genau **eine aktive Tasche**. + +Beispiel: + +```text +HIDE +→ Einfacher Fellbeutel +→ 5 Kapazität + +TROPHY +→ Kleine Jagdtasche +→ 4 Kapazität + +HUMANOID_SPOILS +→ Kleiner Plünderbeutel +→ 5 Kapazität +``` + +Wird eine bessere Tasche ausgerüstet, ersetzt sie die bisher aktive Tasche dieser Kategorie. + +Keine Addition mehrerer identischer Taschen. + +Nicht: + +```text +5 Fellbeutel × 5 Plätze = 25 +``` + +Sondern: + +```text +aktiver Fellbeutel = 10 Plätze +``` + +Dadurch bleibt das System verständlich und leicht zu balancieren. + +--- + +# 15. Kapazitätsberechnung + +Für jede Loot Category wird berechnet: + +```text +verwendete Kapazität +/ +maximale Kapazität +``` + +Beispiel: + +```text +Fellbeutel +3 / 5 +``` + +Wenn der Spieler ein weiteres Fell erhält: + +```text +4 / 5 +``` + +Bei: + +```text +5 / 5 +``` + +ist die Tasche voll. + +--- + +# 16. Loot bei voller Tasche + +Wenn ein Gegner Beute einer Loot Category fallen lässt, deren Tasche voll ist, darf die Kapazitätsgrenze nicht überschritten werden. + +V1-Regel: + +**Nicht tragbare Handelsbeute wird zurückgelassen.** + +Beispiel: + +```text +Aschenfell gefunden + +Fellbeutel: +5 / 5 + +Ergebnis: +Aschenfell kann nicht aufgenommen werden. +``` + +Der Spieler erhält eine klare Nachricht. + +Beispiel: + +> Dein Fellbeutel ist voll. + +Der Kampf selbst bleibt vollständig abgeschlossen. + +--- + +# 17. Equipment bei voller Beutetasche + +Equipment und andere normale Inventargegenstände sind unabhängig von Beutetaschen. + +Beispiel: + +Ein Wolf droppt: + +- Dämmerfell +- Schwarzmähnenzahn als Material +- seltene Waffe + +Ist der Fellbeutel voll: + +- Dämmerfell kann nicht aufgenommen werden. +- Trophy kann aufgenommen werden, wenn dort Kapazität vorhanden ist. +- Waffe wird regulär über das normale Inventar verarbeitet. + +Jeder Loot-Eintrag wird unabhängig behandelt. + +--- + +# 18. Keine automatische Umwandlung + +Beute darf bei voller Tasche nicht automatisch in: + +- Silber +- Ruf +- andere Währungen + +umgerechnet werden. + +Das würde den Sinn des Taschensystems umgehen. + +Der Spieler muss die Beute tatsächlich zu einer geeigneten Stelle bringen. + +--- + +# 19. Beute wird nicht automatisch verkauft + +Das Töten eines Monsters erzeugt keinen unmittelbaren wirtschaftlichen Gewinn. + +Der Server gewährt zunächst ausschließlich die tatsächlich erhaltene Beute. + +Beispiel: + +```text +Wolf besiegt + +Erhalten: +Dämmerfell ×1 +Wolfsklaue ×1 +``` + +Erst eine spätere Händlerinteraktion kann daraus beispielsweise: + +```text +Silber +Regionalruf +Weltruhm +``` + +erzeugen. + +Das Händler- und Rufsystem wird in einer separaten Spezifikation definiert. + +--- + +# 20. Taschenprogression + +Taschen stellen eine eigene Form von Charakterfortschritt dar. + +Typische Progression: + +| Stufe | Kapazität | +|---|---:| +| provisorisch | 1 | +| einfach | 5 | +| verstärkt | 10 | +| hochwertig | 15 | +| erfahren | 25 | + +Dies sind Richtwerte und keine endgültigen Balancingwerte. + +--- + +# 21. Quellen größerer Taschen + +Bessere Taschen können langfristig über verschiedene Systeme erreichbar sein. + +Geeignete Quellen: + +- Händler +- Rufstufen +- Quests +- seltene Drops +- Gebietshändler +- Crafting +- Berufe +- besondere Erfolge + +V1 benötigt nicht alle diese Quellen. + +Taschen sollten jedoch reguläre Progressionsgegenstände sein und keine Premiummechanik. + +--- + +# 22. Taschen und Regionprogression + +Taschen dürfen passend zu Regionen oder Gegnertypen eingeführt werden. + +Beispiel: + +## Aschenfelder + +relevant: + +- HIDE +- HUMANOID_SPOILS +- COIN + +## Dämmerwald + +zusätzlich stärker relevant: + +- TROPHY + +## Vergessene Ruinen + +neu: + +- RELIC + +Dadurch kann jedes Gebiet zusätzlich einen kleinen wirtschaftlichen Systemfortschritt einführen. + +--- + +# 23. Keine Tasche pro Gegner + +Es wird ausdrücklich kein separates Behältnis für jeden Gegnertyp erstellt. + +Nicht: + +- Rattenbeutel +- Wolfsbeutel +- Hirschbeutel +- Spinnenbeutel + +Stattdessen: + +- Fellbeutel +- Jagdtasche +- Plünderbeutel +- Münztasche +- Reliquienbehälter + +Grundsatz: + +> Taschen bilden breite wirtschaftliche Beutekategorien ab, keine einzelnen Monster. + +--- + +# 24. UI-Darstellung + +Die aktuelle Taschenkapazität muss leicht sichtbar sein. + +Mindestens im Inventar oder in einem eigenen Taschenbereich. + +Beispiel: + +```text +Fellbeutel +████████░░ +8 / 10 +``` + +Oder: + +```text +Felle +8 / 10 +``` + +Eine fast volle Tasche darf visuell hervorgehoben werden. + +Eine volle Tasche benötigt einen klaren Zustand. + +--- + +# 25. Loot-UI + +Bei Kampfergebnissen sollte sichtbar sein, in welche Tasche ein Gegenstand aufgenommen wurde. + +Beispiel: + +```text +Aschenfell ×1 +→ Fellbeutel 4 / 5 +``` + +Wenn keine Kapazität vorhanden ist: + +```text +Aschenfell ×1 +Nicht aufgenommen – Fellbeutel voll +``` + +Der Spieler soll niemals rätseln müssen, warum ein Gegenstand fehlt. + +--- + +# 26. Taschenübersicht + +Das Inventar sollte langfristig einen separaten Abschnitt besitzen: + +**Taschen** + +Beispiel: + +```text +Fellbeutel 8 / 10 +Jagdtasche 3 / 5 +Plünderbeutel 5 / 10 +Münztasche 12 / 20 +Reliquienbehälter nicht vorhanden +``` + +Eine noch nicht vorhandene Tasche darf angezeigt werden, wenn dies für den Spieler hilfreich ist. + +--- + +# 27. Fehlt eine Tasche vollständig + +Besitzt der Spieler keine passende Tasche, gilt für V1: + +**Kapazität = 0** + +Alternativ können einzelne Tutorialsysteme eine implizite Kapazität von 1 vergeben. + +Die fachliche Regel sollte jedoch eindeutig sein. + +Empfehlung: + +```text +Keine Tasche +→ 0 Kapazität +``` + +Ein provisorischer Beutel mit Kapazität 1 wird als echtes Item vergeben, wenn Gameplay eine minimale Transportkapazität benötigt. + +Dadurch gibt es keine versteckten Sonderregeln. + +--- + +# 28. Serverautorität + +Das Taschensystem ist vollständig serverautoritativ. + +Der Client darf nicht bestimmen: + +- ob ein Gegenstand aufgenommen werden kann +- welche Tasche verwendet wird +- wie viel Kapazität verfügbar ist +- ob eine Tasche ausgerüstet ist +- wie viele Gegenstände ein Spieler trägt + +Der Server prüft jeden Loot Grant. + +--- + +# 29. Loot-Grant-Ablauf + +Für einen kategorisierten Gegenstand: + +```text +Loot Roll erfolgreich +→ ItemDefinition laden +→ Loot Category bestimmen +→ aktive kompatible Tasche bestimmen +→ aktuelle Nutzung berechnen +→ freie Kapazität prüfen +→ Item gewähren oder zurücklassen +→ Ergebnis an Client senden +``` + +Für Equipment: + +```text +Loot Roll erfolgreich +→ normales Inventory-System +``` + +--- + +# 30. Kapazitätsprüfung + +Konzeptionell: + +```ts +canStoreLoot( + characterId: string, + itemDefinitionId: string, + quantity: number, +): BagCapacityResult +``` + +Mögliches Ergebnis: + +```ts +interface BagCapacityResult { + canStoreAll: boolean; + acceptedQuantity: number; + rejectedQuantity: number; + bagKey?: string; + usedCapacity: number; + maxCapacity: number; +} +``` + +--- + +# 31. Teilweise Aufnahme + +Wenn mehrere Einheiten gleichzeitig gedroppt werden, darf eine teilweise Aufnahme erfolgen. + +Beispiel: + +```text +Fellbeutel: +4 / 5 + +Drop: +Aschenfell ×3 +``` + +Ergebnis: + +```text +aufgenommen: 1 +zurückgelassen: 2 +``` + +Danach: + +```text +5 / 5 +``` + +Dies muss im Loot-Ergebnis klar dargestellt werden. + +--- + +# 32. Relevante technische Enums + +Konzeptionell: + +```ts +export enum MonsterCategory { + BEAST = 'BEAST', + HUMANOID = 'HUMANOID', + UNDEAD = 'UNDEAD', + INSECT = 'INSECT', + ABERRATION = 'ABERRATION', +} +``` + +```ts +export enum LootCategory { + HIDE = 'HIDE', + TROPHY = 'TROPHY', + HUMANOID_SPOILS = 'HUMANOID_SPOILS', + COIN = 'COIN', + RELIC = 'RELIC', +} +``` + +Diese Enums eignen sich für das bestehende `game-content`- beziehungsweise Shared-Content-Modell. + +--- + +# 33. Erforderliche Content-Erweiterungen + +Alle bereits vorhandenen Monster müssen um eine Monster Category ergänzt werden. + +Beispielhafte Zuordnung des bestehenden Contents: + +## Aschenfelder + +| Gegner | Monster Category | +|---|---| +| Aschenratte | BEAST | +| Verwilderter Straßenhund | BEAST | +| Straßenräuber | HUMANOID | +| Plünderer-Späher | HUMANOID | +| Plünderer-Veteran | HUMANOID | +| Verkohlter Plünderer | HUMANOID | +| Aschenwühler | ABERRATION | +| Verbrannter Jagdhund | BEAST | +| Hauptmann der Aschenbande | HUMANOID | + +## Dämmerwald + +| Gegner | Monster Category | +|---|---| +| Dämmerwolf | BEAST | +| Moorkrabbler | ABERRATION | +| Waldplünderer | HUMANOID | +| Giftspinne | INSECT | +| Verdorbener Hirsch | BEAST | +| Schwarzmähnenwolf | BEAST | +| Dornenbestie | ABERRATION | +| Giftweberin | INSECT | +| Graufang | BEAST | +| Schattenalpha | BEAST | + +## Vergessene Ruinen + +| Gegner | Monster Category | +|---|---| +| Verlorener Soldat | UNDEAD | +| Grabräuber | HUMANOID | +| Ruinenwächter | UNDEAD | +| Knochenrufer | UNDEAD | +| Gefallener Ritter | UNDEAD | +| Grabkriecher | ABERRATION | +| Namenloser Bannerträger | UNDEAD | +| Aschenpriester | HUMANOID | +| Grabwächter | UNDEAD | +| Verdorbener Akolyth | HUMANOID | +| Knochenritter | UNDEAD | +| Sir Varos | UNDEAD | +| Knochenfürst | UNDEAD | + +Diese Zuordnung ist eine erste fachliche Einordnung und kann beim Content-Review noch angepasst werden. + +--- + +# 34. Bestehende Materialien müssen kategorisiert werden + +Beispiele aus dem aktuellen Loot-Design: + +| Item | Loot Category | +|---|---| +| Aschenfell / Tierrest | HIDE | +| Zähes Fell | HIDE | +| Verkohlte Chitinplatte | TROPHY | +| Dämmerfell | HIDE | +| Moorkarapax | TROPHY | +| Giftdrüse | TROPHY | +| Bannerfragment der letzten Wacht | QUEST_ITEM / keine Bag Category | + +Das Bannerfragment bleibt wegen seiner Quest-/Lore-Funktion außerhalb des normalen Taschensystems. + +--- + +# 35. Neue humanoide Handelsbeute + +Da humanoide Gegner bisher häufig direkt Silber liefern, sollte das neue Ruf- und Taschensystem diese Drops langfristig durch physische Handelsware ersetzen. + +Beispiele: + +- Plündererabzeichen +- gestohlene Münzen +- Räuberplakette +- Veteraneninsignie +- verbranntes Bandenzeichen + +Diese Gegenstände können Kategorien wie: + +- HUMANOID_SPOILS +- COIN + +verwenden. + +Die konkreten Händlerwerte werden separat gebalanced. + +--- + +# 36. Neue Untotenbeute + +Für die Vergessenen Ruinen sollten physische Handelswaren eingeführt werden. + +Beispiele: + +- verwittertes Siegel +- Knochenfragment +- Grabmünze +- Reliquienrest +- Zeichen der letzten Wacht + +Diese verwenden hauptsächlich: + +`RELIC` + +Einzelne Grabmünzen können alternativ: + +`COIN` + +verwenden. + +--- + +# 37. Nicht jeder Gegner muss jede Kategorie droppen + +Monster Categories definieren keine verpflichtende Anzahl von Drops. + +Beispiel: + +Ein Wolf kann ausschließlich Fell droppen. + +Ein stärkerer Wolf kann Fell und Trophy droppen. + +Ein Boss kann zusätzlich Equipment droppen. + +Loot Tables bleiben bewusst individuell. + +--- + +# 38. Taschen dürfen Loot-Identität verstärken + +Taschen sollen sichtbar machen, welche Art von Beute eine Region prägt. + +Beispiele: + +Aschenfelder: + +> Felle und Plünderergut + +Dämmerwald: + +> Felle und Jagdtrophäen + +Vergessene Ruinen: + +> Reliquien und Grabbeute + +Damit werden Regionen wirtschaftlich unterscheidbarer. + +--- + +# 39. Keine Taschenpflicht für Equipment-Progression + +Ein Spieler darf niemals daran gehindert werden, ein relevantes Equipment-Upgrade zu erhalten, nur weil eine Beutetasche voll ist. + +Equipment verwendet weiterhin das normale Inventarsystem. + +Das Taschensystem begrenzt primär: + +- Handelsware +- Materialien +- spätere Crafting-Ressourcen + +nicht den Kern-Loot der Charakterprogression. + +--- + +# 40. Verhältnis zum Rufsystem + +Das Taschensystem bildet die Transportebene des neuen Ruf- und Wirtschaftskreislaufs. + +Grundloop: + +```text +Monster +→ physische Beute +→ passende Tasche +→ Händler / NPC +→ Verwertung +→ Silber / Regionalruf / Weltruhm +``` + +Der genaue Umrechnungsschritt wird nicht in dieser Spezifikation definiert. + +--- + +# 41. Verhältnis zu Crafting + +Crafting ist weiterhin nicht Bestandteil des ersten Vertical Slice. + +Materialien sollten trotzdem so modelliert werden, dass sie später weiterverwendet werden können. + +Beispiel: + +Heute: + +```text +Dämmerfell +→ Handelsware +``` + +Später: + +```text +Dämmerfell +→ Handelsware +oder +→ Lederverarbeitung +``` + +Die Loot Category muss dafür nicht verändert werden. + +--- + +# 42. Verhältnis zum normalen Inventar + +Die bisherige Regel eines einfachen slotbasierten Inventars bleibt bestehen. + +Beutetaschen ersetzen dieses System nicht. + +Trennung: + +```text +Equipment +→ Inventar + +normale Items +→ Inventar + +Kampfverbrauchsitems +→ Inventar + Kampftasche + +Questitems +→ Questinventar + +kategorisierte Handelsbeute +→ Beutetaschen +``` + +--- + +# 43. Keine unnötige Mikromanagement-Komplexität + +Für V1 ausdrücklich nicht enthalten: + +- Gewichtsberechnung +- unterschiedliche Itemgrößen +- Tetris-Inventar +- Taschen in Taschen +- manuelles Verschieben einzelner Materialien zwischen Taschen +- mehrere Taschen derselben Kategorie gleichzeitig +- Verschleiß von Taschen +- zufällige Taschenattribute +- Bag Enchantments +- Qualitätsboni auf Verkaufspreise +- automatisches Sortieren durch den Spieler konfigurieren + +--- + +# 44. Datengetriebene Architektur + +Das System soll ohne monsterspezifische Sonderprogrammierung funktionieren. + +Neue Inhalte sollen hauptsächlich durch Daten entstehen: + +```text +MonsterDefinition +→ MonsterCategory + +LootTable +→ ItemDefinition + +ItemDefinition +→ LootCategory + +BagDefinition +→ supportedLootCategories +→ capacity +``` + +Dadurch kann ein neuer Gegner ohne Änderung des Kerncodes neue kategorisierte Beute erhalten. + +--- + +# 45. Content-Validierung + +Beim Seed oder später im CMS sollten Plausibilitätsprüfungen möglich sein. + +Beispiele: + +Ein `TRADE_GOOD` sollte normalerweise eine Loot Category besitzen. + +Ein Equipment-Item sollte normalerweise keine Loot Category besitzen. + +Eine BagDefinition muss mindestens eine unterstützte Loot Category besitzen. + +Kapazität muss größer als 0 sein. + +Loot Categories müssen als gültige Enumwerte existieren. + +--- + +# 46. API-Ausgabe + +Inventar- oder Character-State sollte die aktiven Taschen mitsenden können. + +Beispiel: + +```json +{ + "bags": [ + { + "key": "simple-hide-pouch", + "name": "Einfacher Fellbeutel", + "lootCategories": ["HIDE"], + "capacity": 5, + "used": 3 + } + ] +} +``` + +Der Client berechnet verfügbare Kapazität nicht selbst. + +--- + +# 47. Loot-Ergebnis + +Das Ergebnis eines Kampfes sollte unterscheiden zwischen: + +```text +erhalten +nicht erhalten +``` + +Beispiel: + +```json +{ + "loot": [ + { + "itemKey": "ash-hide", + "rolledQuantity": 2, + "acceptedQuantity": 1, + "rejectedQuantity": 1, + "reason": "BAG_FULL" + } + ] +} +``` + +Dadurch kann die UI korrekt erklären, was passiert ist. + +--- + +# 48. Erste Implementierungsreihenfolge + +Empfohlene Reihenfolge: + +1. `MonsterCategory` einführen. +2. Bestehende Monster kategorisieren. +3. `LootCategory` einführen. +4. Materialien und Handelswaren kategorisieren. +5. `BagDefinition` erstellen. +6. `CharacterBag` erstellen. +7. Kapazitätsservice implementieren. +8. LootService um Bag-Prüfung erweitern. +9. Loot-API um akzeptierte und zurückgelassene Beute erweitern. +10. Taschenübersicht im Inventar anzeigen. +11. Bestehende direkten Monster-Silberdrops später auf physische Handelsware umstellen. +12. Händler- und Rufsystem daran anbinden. + +--- + +# 49. Definition of Done + +Das Taschensystem ist für V1 vollständig implementiert, wenn: + +- jedes relevante Monster eine Monster Category besitzt +- Handelsmaterialien eine Loot Category besitzen +- der Spieler passende Taschen besitzen kann +- Taschen eine feste Kapazität besitzen +- der Server Kapazität vor Lootvergabe prüft +- teilweise Lootaufnahme unterstützt wird +- volle Taschen keine Equipment-Drops blockieren +- Questitems keine Taschenkapazität verbrauchen +- die UI aktuelle und maximale Kapazität zeigt +- Loot-Ergebnisse zurückgelassene Beute eindeutig anzeigen +- das System datengetrieben um neue Kategorien erweitert werden kann + +--- + +# 50. Kurzfassung + +Ashen Realms verwendet spezialisierte Beutetaschen für kategorisierte Materialien und Handelswaren. + +Monster besitzen eine: + +**Monster Category** + +Gegenstände besitzen optional eine: + +**Loot Category** + +Taschen unterstützen bestimmte Loot Categories und besitzen eine feste Kapazität. + +Beispiel: + +```text +Dämmerwolf +Monster Category: BEAST + +Drops: +Dämmerfell → HIDE +Wolfsklaue → TROPHY + +Fellbeutel: +8 / 10 + +Jagdtasche: +3 / 5 +``` + +Das System erzeugt dadurch einen natürlichen Rhythmus aus: + +**Jagen → Taschen füllen → zurückkehren → Beute verwerten → Taschen verbessern → längere Expeditionen durchführen** + +Der wichtigste Grundsatz lautet: + +> Taschen sollen Expeditionen strukturieren und Fortschritt sichtbar machen, ohne das Inventar in ein kompliziertes Verwaltungs- oder Gewichtssystem zu verwandeln. \ No newline at end of file