Commencez par la fonction, pas par le nom poétique
Les joueurs voient un nom immersif. L’équipe a besoin d’un identifiant stable. L’ID interne doit répondre à une question simple: qu’est-ce que cet objet dans le projet, indépendamment du wording de lore. Un artefact peut donc s’appeler relic_sun_seal même si les joueurs lisent Sceau de la Quatrième Porte.
La règle la plus utile consiste à séparer volontairement le nom visible et le nom système. Le titre peut rester élégant. Le hidden ID, lui, doit rester calme, précis et lisible pour quelqu’un qui n’a pas participé à la discussion d’origine.
Un schéma de nommage qui survit à la croissance
Une formule robuste est catégorie + famille + variante. Par exemple: currency_bone_token, quest_marshal_writ, relic_storm_core, prop_court_seal. L’idée n’est pas la beauté. L’idée est que l’œil voie immédiatement sur quelle étagère ranger l’objet.
Une fois ce schéma en place, les alertes de doublons deviennent beaucoup plus utiles. On ne voit plus deux lignes arbitraires mais deux objets qui se battent pour le même emplacement dans la même famille.
Quand le hook visuel doit faire écho
Le hook visuel n’a pas besoin de répéter tout l’ID interne, mais il doit rester reconnaissable. Si l’objet s’appelle relic_storm_core, le chemin item_model ou la note CMD ne devrait pas se cacher derrière une abréviation sans lien. Un simple écho suffit: storm_core, relic/storm_core, ritual/storm_core.
Cela compte particulièrement pendant le travail de pack. Si le catalogue dit une chose et le chemin de modèle une autre, l’équipe perd du temps à prouver qu’il s’agit bien du même objet.
Les champs minimums à garder
| Champ | Question | Bon signe |
|---|---|---|
| Internal ID | Quel est cet objet pour le système? | Stable et facile à rechercher. |
| Visible name | Que voit le joueur? | Immersif et lisible. |
| Visual hook | Quelle icône ou quel modèle lui correspond? | Traçable sans friction. |
| Notes | Qu’est-ce qui le rend spécial? | Assez clair pour éviter de deviner plus tard. |
Vous n’avez pas besoin d’une bureaucratie énorme. Vous avez besoin d’assez de structure pour qu’un objet survive à un passage de main.
Erreurs fréquentes
- Nommer uniquement selon l’apparence, au point que l’ID devient inutile après un redesign.
- Utiliser des abréviations qu’une seule personne comprend.
- Laisser plusieurs prototypes partager le même hidden ID parce que la différence semble temporaire.
- Changer de style de nommage au milieu d’une série de contenu sans marquer l’ancienne famille.
Ces erreurs paraissent modestes au début et coûteuses quelques semaines plus tard.
FAQ
Le nom visible et l’ID doivent-ils être identiques?
Pas forcément. C’est pratique parfois, mais ce n’est pas une obligation.
À partir de quand la structure devient-elle trop lourde?
Si l’ID se lit encore d’un coup d’œil, c’est probablement bon. S’il ressemble à un paragraphe, il faut le réduire.
Une famille peut-elle partager un même hook visuel?
Oui, si c’est assumé. Le catalogue doit rendre ce partage visible, pas accidentel.