Start with the job, not the cool name
Players can see poetic names. Your team needs stable names. An internal ID should answer a boring but vital question: what is this object in the project, independent from its lore wording. That is why a relic can still be called relic_sun_seal even if players only see Sun Seal of the Fourth Gate.
Let the visible title stay immersive. Let the hidden ID stay precise, searchable, and useful to someone who joined the project later.
A pattern that survives growth
A practical pattern is category + family + variant. For example: currency_bone_token, quest_marshal_writ, relic_storm_core, prop_court_seal. The goal is not beauty. The goal is that the eye instantly knows what shelf the item belongs on.
Once the pattern exists, duplicate warnings become informative instead of mysterious. You stop seeing random collisions and start seeing two objects fighting over the same slot in the same family.
Where visual hooks should echo the ID
A visual hook does not need to repeat the entire internal ID, but it should still be recognizable. If the item is relic_storm_core, then the item_model or CMD note should not hide behind a completely unrelated shorthand. A partial echo is enough: storm_core, relic/storm_core, or ritual/storm_core.
This matters most during pack work. If the catalog says one thing and the model path says another, the team wastes time proving that two names are actually the same object.
Minimum naming fields
| Field | Question | Good sign |
|---|---|---|
| Internal ID | What is this object in system language? | Stable and searchable. |
| Visible name | What do players see? | Immersive and readable. |
| Visual hook | Which model or icon belongs to it? | Clearly traceable. |
| Notes | What makes this one special? | Enough to avoid future guesswork. |
You do not need giant bureaucracy. You just need enough structure that the same object survives a handoff.
Common mistakes
- Naming by appearance only, so the ID becomes useless after one redesign.
- Using abbreviations that only one teammate understands.
- Letting multiple prototypes keep the same hidden ID because the difference feels temporary.
- Changing naming style halfway through a content arc without marking the old family.
These mistakes feel harmless on day one and expensive on day twenty.
FAQ
Should visible names and IDs ever match exactly?
Sometimes, but they do not need to. Matching is convenient, not required.
How much structure is too much?
If people can still read the ID in one glance, it is probably fine. If the ID becomes a paragraph, cut it back.
Can one item family share one visual hook?
Yes, if that decision is explicit. The catalog should make shared hooks visible, not accidental.