Erst die Aufgabe benennen, dann den hübschen Namen
Spieler sehen einen atmosphärischen Namen. Das Team braucht eine stabile technische Identität. Eine Internal ID sollte eine einfache Frage beantworten: Was ist dieses Objekt im Projektsystem, unabhängig von seiner Lore-Formulierung? Deshalb kann ein Artefakt ruhig relic_sun_seal heißen, auch wenn Spieler nur Sonnensiegel des vierten Tores lesen.
Die hilfreichste Regel ist, sichtbaren Namen und Systemnamen bewusst zu trennen. Der Titel darf immersiv sein. Die hidden ID sollte ruhig, präzise und auch für Leute lesbar sein, die beim ursprünglichen Designgespräch nicht dabei waren.
Ein Benennungsmuster, das Wachstum überlebt
Eine robuste Formel ist Kategorie + Familie + Variante. Zum Beispiel: currency_bone_token, quest_marshal_writ, relic_storm_core, prop_court_seal. Es geht nicht um Eleganz. Es geht darum, dass das Auge sofort erkennt, in welches Regal das Objekt gehört.
Sobald dieses Muster steht, werden Duplicate-Warnungen viel nützlicher. Ihr seht dann nicht bloß zwei zufällige Zeilen, sondern zwei Objekte, die denselben Slot derselben Familie beanspruchen.
Wo der Visual Hook mitschwingen sollte
Der Visual Hook muss nicht die komplette Internal ID wiederholen, aber er sollte wiedererkennbar sein. Wenn das Item relic_storm_core heißt, sollte der item_model-Pfad oder CMD-Hinweis nicht hinter einer völlig fremden Kurzform verschwinden. Ein Teil-Echo reicht: storm_core, relic/storm_core, ritual/storm_core.
Gerade bei Pack-Arbeit spart das Zeit. Wenn Katalog und Modellpfad unterschiedliche Sprachen sprechen, verbringt das Team unnötig viel Zeit damit, dieselbe Sache zweimal zu identifizieren.
Die minimale Feldstruktur
| Feld | Welche Frage beantwortet es? | Gutes Zeichen |
|---|---|---|
| Internal ID | Was ist das Objekt im System? | Stabil und gut suchbar. |
| Visible name | Was sehen Spieler? | Immersiv und lesbar. |
| Visual hook | Welches Modell oder Icon gehört dazu? | Ohne Reibung nachvollziehbar. |
| Notes | Was macht dieses Item besonders? | Genug Kontext, damit später nicht geraten werden muss. |
Ihr braucht keine riesige Bürokratie. Ihr braucht nur genug Struktur, damit ein Item eine Übergabe überlebt.
Häufige Fehler
- Nur nach Aussehen benennen, sodass die ID nach einem Redesign wertlos wird.
- Abkürzungen verwenden, die nur eine Person versteht.
- Mehrere Prototypen denselben hidden ID teilen lassen, weil der Unterschied nur vorläufig wirkt.
- Mitten in einer Content-Linie den Benennungsstil wechseln, ohne die alte Familie zu markieren.
Diese Fehler wirken früh harmlos und später teuer.
FAQ
Müssen sichtbarer Name und ID exakt gleich sein?
Nicht unbedingt. Es kann praktisch sein, ist aber keine Pflicht.
Wann ist die Struktur zu schwer?
Wenn die ID noch in einem Blick lesbar ist, ist sie meist okay. Wenn sie wie ein Absatz wirkt, sollte sie kürzer werden.
Kann eine Familie denselben Visual Hook teilen?
Ja, solange das bewusst dokumentiert ist. Der Katalog sollte geteilte Hooks sichtbar machen, nicht zufällig verstecken.