bastian/ashen-realms

Fork 0

Files

Bastian Wagner 8a5f57fa1c specs

2026-08-20 16:17:19 +02:00

25 KiB

Raw Blame History

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:

Expeditionen sollen eine natürliche Länge erhalten.
Rückkehr zu Händlern und sicheren Orten soll spielerisch sinnvoll sein.
Taschen sollen selbst Teil der Progression sein.
Unterschiedliche Gegnerarten sollen unterschiedliche wirtschaftliche Identitäten erhalten.
Beute soll thematisch zum Gegner passen.
Größere Taschen sollen spürbaren Komfort und Fortschritt erzeugen.
Das System darf keine komplizierte Gewichtssimulation erzeugen.
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:

ItemDefinition {
  ...
  itemType
  lootCategory?
}

Beispiel:

{
  key: 'ash-hide',
  name: 'Aschenfell',
  itemType: 'TRADE_GOOD',
  lootCategory: 'HIDE'
}

Equipment besitzt keine Loot Category.

Beispiel:

{
  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:

monsterCategories: MonsterCategory[]

V1 kann technisch auch genau eine Hauptkategorie verwenden.

Das Modell sollte jedoch eine spätere Mehrfachzuordnung nicht unnötig verhindern.

Beispiel:

{
  key: 'ash-rat',
  name: 'Aschenratte',
  monsterCategories: ['BEAST']
}

Später könnte ein Gegner beispielsweise sein:

['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:

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:

BagDefinition {
  id
  key
  name
  description
  supportedLootCategories
  capacity
  tier
  iconPath
}

Beispiel:

{
  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:

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:

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:

5 Fellbeutel × 5 Plätze = 25

Sondern:

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:

verwendete Kapazität
/
maximale Kapazität

Beispiel:

Fellbeutel
3 / 5

Wenn der Spieler ein weiteres Fell erhält:

4 / 5

Bei:

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:

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:

Wolf besiegt

Erhalten:
Dämmerfell ×1
Wolfsklaue ×1

Erst eine spätere Händlerinteraktion kann daraus beispielsweise:

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:

Fellbeutel
████████░░
8 / 10

Oder:

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:

Aschenfell ×1
→ Fellbeutel 4 / 5

Wenn keine Kapazität vorhanden ist:

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:

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:

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:

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:

Loot Roll erfolgreich
→ normales Inventory-System

30. Kapazitätsprüfung

Konzeptionell:

canStoreLoot(
  characterId: string,
  itemDefinitionId: string,
  quantity: number,
): BagCapacityResult

Mögliches Ergebnis:

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:

Fellbeutel:
4 / 5

Drop:
Aschenfell ×3

Ergebnis:

aufgenommen: 1
zurückgelassen: 2

Danach:

5 / 5

Dies muss im Loot-Ergebnis klar dargestellt werden.

32. Relevante technische Enums

Konzeptionell:

export enum MonsterCategory {
  BEAST = 'BEAST',
  HUMANOID = 'HUMANOID',
  UNDEAD = 'UNDEAD',
  INSECT = 'INSECT',
  ABERRATION = 'ABERRATION',
}

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:

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:

Dämmerfell
→ Handelsware

Später:

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:

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:

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:

{
  "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:

erhalten
nicht erhalten

Beispiel:

{
  "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:

MonsterCategory einführen.
Bestehende Monster kategorisieren.
LootCategory einführen.
Materialien und Handelswaren kategorisieren.
BagDefinition erstellen.
CharacterBag erstellen.
Kapazitätsservice implementieren.
LootService um Bag-Prüfung erweitern.
Loot-API um akzeptierte und zurückgelassene Beute erweitern.
Taschenübersicht im Inventar anzeigen.
Bestehende direkten Monster-Silberdrops später auf physische Handelsware umstellen.
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:

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.

25 KiB Raw Blame History Unescape Escape

Ashen Realms – Loot Bags & Monster Loot Categories Specification V1

Zweck dieser Dokumentation

1. Grundprinzip

Normales Inventar

Kampftasche

Questinventar

Beutetaschen

2. Designziele

3. Kein Gewichtssystem

4. Loot Categories

HIDE

TROPHY

HUMANOID_SPOILS

COIN

RELIC

5. Erweiterbare Kategorien

6. Monster Categories

7. Zweck der Monster Categories

8. Monster Category und Loot Category bleiben getrennt

9. ItemDefinition-Erweiterung

10. MonsterDefinition-Erweiterung

11. Loot bleibt über Loot Tables definiert

12. BagDefinition

13. CharacterBag

14. V1-Ausrüstungsmodell für Taschen

15. Kapazitätsberechnung

16. Loot bei voller Tasche

17. Equipment bei voller Beutetasche

18. Keine automatische Umwandlung

19. Beute wird nicht automatisch verkauft

20. Taschenprogression

21. Quellen größerer Taschen

22. Taschen und Regionprogression

Aschenfelder

Dämmerwald

Vergessene Ruinen

23. Keine Tasche pro Gegner

24. UI-Darstellung

25. Loot-UI

26. Taschenübersicht

27. Fehlt eine Tasche vollständig

28. Serverautorität

29. Loot-Grant-Ablauf

30. Kapazitätsprüfung

31. Teilweise Aufnahme

32. Relevante technische Enums

33. Erforderliche Content-Erweiterungen

Aschenfelder

Dämmerwald

Vergessene Ruinen

34. Bestehende Materialien müssen kategorisiert werden

35. Neue humanoide Handelsbeute

36. Neue Untotenbeute

37. Nicht jeder Gegner muss jede Kategorie droppen

38. Taschen dürfen Loot-Identität verstärken

39. Keine Taschenpflicht für Equipment-Progression

40. Verhältnis zum Rufsystem

41. Verhältnis zu Crafting

42. Verhältnis zum normalen Inventar

43. Keine unnötige Mikromanagement-Komplexität

44. Datengetriebene Architektur

45. Content-Validierung

46. API-Ausgabe

47. Loot-Ergebnis

48. Erste Implementierungsreihenfolge

49. Definition of Done

50. Kurzfassung

25 KiB

Raw Blame History