Warum das früher nötig wird, als man denkt
Fast kein Server startet mit einem formalen Register. Meist beginnt alles mit ein paar Props, einer Währung, einem Quest-Pass und der Hoffnung, dass sich die Gruppe schon merken wird, welcher hidden ID zu welchem Objekt gehört. Diese Hoffnung bricht viel früher, als die Bibliothek überhaupt groß wirkt.
Der Katalog existiert nicht, um bürokratisch auszusehen. Er existiert, weil Erinnerung das erste ist, was schlecht skaliert. Sobald mehrere Builder, Autor:innen oder Pack-Leute dieselbe Item-Bibliothek anfassen, braucht ihr pro Objekt eine stabile Zeile statt noch einen Chat, der später durchsucht werden muss.
Die Mindestzeile, die jedes Item haben sollte
| Feld | Welche Frage es beantwortet | Warum das wichtig ist |
|---|---|---|
| Internal ID | Unter welchem Logiknamen das Item lebt. | Verhindert, dass zwei Objekte dieselbe Identität teilen. |
| Visible name | Was Spieler tatsächlich sehen. | Trennt immersiven Namen von technischem Namen. |
| Base item | Welches Vanilla-Item darunter liegt. | Nützlich für Pack-Prüfungen und schnelle Sanity Checks. |
| Visual hook | Welche item_model- oder CMD-Verzweigung gekoppelt ist. | Hält die visuelle Seite nah an der Logik. |
| Status / owner | Wer gerade an diesem Item arbeitet. | Reduziert versehentliche Überschneidungen bei Überarbeitungen. |
| Notes | Was dieses Item besonders macht. | Verhindert, dass Sonderfälle im Chatverlauf verschwinden. |
Ein Team-Workflow, der lesbar bleibt
- Skizziert das Item zuerst im Custom-Item-Builder oder in euren Design-Notizen.
- Erstellt den Katalogeintrag, bevor sich das Item über Befehle, Art und Scripts verteilt.
- Nutzt Tags und Notes, um zu markieren, ob es Währung, Prop, Quest-Objekt, Belohnung oder Testmüll ist.
- Exportiert nach JSON, CSV oder Markdown, sobald die Sammlung aus einem einzelnen Browser heraus in die Teamarbeit wandern soll.
Diese Reihenfolge ist wichtig. Der Katalog ist am stärksten, wenn er Entscheidungen früh festhält und nicht erst nach einer chaotischen Release-Woche rekonstruieren muss.
Was die Duplikat-Warnungen wirklich bedeuten
Eine Warnung für duplicate hidden ID bedeutet, dass zwei Einträge denselben logischen Slot beanspruchen. Das ist gefährlich, weil Befehle, Belohnungen oder Scripts plötzlich auf das falsche Objekt zeigen können.
Eine duplicate visual hook-Warnung ist weicher, aber trotzdem wichtig. Oft heißt sie, dass zwei Einträge absichtlich oder versehentlich dieselbe Optik teilen. In beiden Fällen hilft eine Note, damit die nächste Person eine bewusste Entscheidung nicht versehentlich „repariert“.
Lokale Browser-Entwürfe können trotzdem teamtauglich sein
Lokaler Browser-Speicher ist hier nicht das Problem. Er ist ein Entwurfsraum. Wichtig ist nur, den Export als den Moment zu behandeln, in dem ein privater Entwurf zu Team-Infrastruktur wird. Ein gesunder Workflow darf lokal beginnen und später in Kanäle, Dokumente oder Reviews wandern.
Genau deshalb sind Import und Export hier so wichtig. Der Katalog darf als persönliche Arbeitsfläche starten, sollte aber nicht dort eingeschlossen bleiben, sobald das Item real wird.
Häufige Fehler
- Nur den sichtbaren Namen notieren und hoffen, dass die technische Seite später schon wieder klar wird.
- Mehrere Prototypen denselben hidden ID teilen lassen, weil „wir das später aufräumen“.
- Nicht markieren, ob ein gemeinsamer visual hook Absicht oder Unfall ist.
- Den Katalog nach Release wie ein Museum behandeln statt wie ein lebendiges Arbeitsdokument.
- Zu spät exportieren, wenn sich die Item-Logik bereits über mehrere Leute verteilt hat.
FAQ
Ist so ein Katalog nur für große Server sinnvoll?
Nein. Er lohnt sich erstaunlich früh, oft genau dann, wenn die Custom-Items nicht mehr problemlos im Kopf einer Person bleiben.
Müssen Visible Name und Internal ID genau gleich sein?
Nicht unbedingt. Der sichtbare Name darf atmosphärisch bleiben. Die Internal ID sollte stabil und teamlesbar sein.
Warum nicht einfach dauerhaft bei einer Tabelle bleiben?
Das geht, aber ein eigener Katalog meldet Duplikate schneller und passt besser zum restlichen Item-Workflow der Seite.
Ersetzt der Katalog den Custom-Item-Builder?
Nein. Der Katalog organisiert die Bibliothek. Der Builder bleibt für die Befehlserstellung zuständig.
Hilft das auch bei Pack-Migrationen?
Ja. Wenn jedes Item sein Base Item und seinen Visual Hook sauber notiert hat, werden Pack-Migrationen deutlich ruhiger.