# 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.