Pourquoi cela devient utile plus tôt qu’on ne le pense
Presque aucun serveur ne commence avec un registre formel. On démarre avec quelques props, une monnaie, un pass de quête et l’idée que l’équipe se souviendra du lien entre chaque hidden ID et son objet. Cette idée casse beaucoup plus tôt que le moment où la bibliothèque semble “grande”.
Le catalogue n’existe pas pour faire administratif. Il existe parce que la mémoire est la première chose qui scale mal. Dès que plusieurs builders, auteurs ou personnes côté pack touchent la même collection, il faut une ligne stable par objet au lieu d’un nouveau fil de discussion à relire.
La ligne minimale que chaque objet devrait avoir
| Champ | Question résolue | Pourquoi c’est utile |
|---|---|---|
| Internal ID | Sous quel nom logique l’objet existe. | Évite que deux objets partagent discrètement la même identité. |
| Visible name | Ce que les joueurs lisent réellement. | Sépare le nom immersif du nom technique. |
| Base item | Quel item vanilla reste dessous. | Pratique pour les vérifications pack-side. |
| Visual hook | À quelle branche item_model ou CMD l’objet est relié. | Empêche l’art de dériver loin de la logique. |
| Status / owner | Qui touche l’objet en ce moment. | Réduit les recouvrements accidentels pendant les révisions. |
| Notes | Ce qui rend cet objet particulier. | Évite que les exceptions se perdent dans l’historique du chat. |
Un workflow d’équipe qui reste lisible
- Esquissez l’objet dans le custom item builder ou dans vos notes de design.
- Créez la ligne du catalogue avant que l’objet se disperse dans les commandes, l’art et les scripts.
- Utilisez les tags et notes pour indiquer s’il s’agit d’une monnaie, d’un prop, d’un objet de quête, d’une récompense ou d’un prototype de test.
- Exportez en JSON, CSV ou Markdown dès que la bibliothèque doit quitter un seul navigateur pour devenir visible à l’équipe.
Cet ordre compte. Le catalogue est le plus fort lorsqu’il capture les décisions tôt, pas lorsqu’il tente de les reconstruire après une semaine de release déjà chaotique.
Ce que les alertes de doublons essaient réellement de dire
Une alerte de duplicate hidden ID signifie que deux lignes essaient d’occuper le même emplacement logique. C’est dangereux, car commandes, récompenses ou scripts peuvent commencer à viser le mauvais objet.
Une alerte de duplicate visual hook est plus douce, mais reste utile. Elle veut souvent dire que deux entrées partagent un même rendu, volontairement ou non. Dans les deux cas, une note évite qu’une personne suivante “corrige” un choix qui était en fait assumé.
Un brouillon local dans le navigateur peut quand même servir une équipe
Le stockage local du navigateur n’est pas un problème en soi. C’est un espace de brouillon. Ce qui compte, c’est de traiter l’export comme le moment où un brouillon privé devient une infrastructure d’équipe. Un workflow sain peut donc commencer localement puis partir vers des salons, des documents ou des revues une fois la ligne stabilisée.
C’est justement pour cela que l’import et l’export comptent autant. Le catalogue peut naître comme une surface de travail personnelle, mais il ne doit pas rester enfermé là si l’objet devient réel.
Erreurs fréquentes
- Ne noter que le nom visible et supposer que la partie technique se reconstituera plus tard.
- Laisser plusieurs prototypes temporaires partager le même hidden ID en se disant qu’on nettoiera plus tard.
- Oublier d’indiquer si un visual hook partagé est volontaire ou accidentel.
- Traiter le catalogue comme un musée après la sortie au lieu d’un document de travail vivant.
- Exporter trop tard, quand la logique de l’objet s’est déjà dispersée entre plusieurs personnes.
FAQ
Ce catalogue n’est-il utile que pour les gros serveurs ?
Non. Il devient rentable très tôt, dès que les objets custom ne tiennent plus confortablement dans la mémoire d’une seule personne.
Le visible name doit-il être identique à l’internal ID ?
Pas forcément. Le nom visible peut rester immersif. L’internal ID doit rester stable et lisible pour l’équipe.
Pourquoi ne pas tout laisser dans un tableur ?
C’est possible, mais un catalogue dédié fait remonter les doublons plus vite et colle mieux au reste du workflow objets du site.
Le catalogue remplace-t-il le custom item builder ?
Non. Le catalogue organise la bibliothèque. Le builder reste l’endroit où l’on génère les commandes.
Est-ce utile aussi lors des migrations de pack ?
Oui. Quand chaque objet possède son base item et son visual hook clairement notés, la migration pack-side devient beaucoup plus calme.