Getly Publisher for Unity

Pourquoi

Dans l’éditeur, elle voit ce qu’aucun serveur ne peut voir : si le GUID de script d’un prefab se résout vraiment, quels sont les réglages d’import d’une texture, comment le compilateur lit un fichier. Mais elle tourne sur la machine du vendeur, dans un package qu’il peut modifier. Se fier à son rapport reviendrait à faire de la barrière ce que dit une copie de notre code sur l’ordinateur de quelqu’un d’autre. L’éditeur conseille donc, et Getly, en lisant les octets envoyés, décide.

Ce que ça a coûté

Deux implémentations des mêmes règles, dans deux langages, qui peuvent diverger. Un catalogue généré et un test qui échoue en cas de dérive, c’est le prix pour les garder honnêtes.

Pourquoi

Une vérification bloquante signifie que l’acheteur reçoit quelque chose de cassé ; un avertissement signifie que la ressource fonctionne et pourrait être meilleure. Allonger la liste des blocages, c’est décider de refuser plus de vendeurs : cela se fait donc délibérément, et la liste est tenue à six. Un vendeur qui connaît sa ressource mieux que nos règles doit pouvoir la publier quand même.

Ce que ça a coûté

Cinq des six, le serveur les trouve seul. La sixième, un prefab qui pointe vers un script absent du package, celle par laquelle tout cet outil commence, demande l’éditeur, car résoudre un GUID, seul Unity sait le faire. Un vendeur qui passe par la voie sans installation obtient les cinq autres mais pas celle-là, et nous préférons le dire plutôt que de laisser cette voie laisser croire le contraire.

Pourquoi

Le test Unity, c’est l’extension et rien d’autre, il ne peut donc refuser qu’un .unitypackage : toutes les fiches qui existaient à sa sortie n’ont pas été touchées, et personne qui ne vendait pas du Unity n’a eu de règle nouvelle à apprendre. Ce n’est plus toute la barrière, puisque la vérification Blender arrivée plus tard doit ouvrir des archives, mais la partie Unity ne touche toujours que Unity.

Ce que ça a coûté

Une ressource Unity livrée dans un .zip n’est pas couverte. Nous l’avons accepté plutôt que de laisser la barrière se forger un avis sur des centaines d’archives qu’elle n’a pas à juger.

Pourquoi

La barrière agit quand un produit est mis en ligne, et des vendeurs avaient des ressources Unity en ligne bien avant l’existence de l’outil. En faire la seule voie aurait obligé un vendeur actif depuis des mois à télécharger un package d’éditeur pour publier une mise à jour. La même vérification tourne donc depuis la page de modification du produit.

Ce que ça a coûté

Deux points d’entrée vers le même cœur, et un bouton dont il faut tenir la portée alignée sur la barrière, ce que nous avons raté une fois et qui a maintenant son test.

Pourquoi

Une clé posée à côté de votre travail est une clé que vous finirez par exporter dans un package et vendre. Les préférences de l’éditeur sont hors du dossier que vous empaquetez, elle ne peut donc pas voyager avec la ressource par accident.

Ce que ça a coûté

Les préférences de l’éditeur sont propres à la machine et à l’utilisateur du système, pas au projet, et la clé y est en clair. Un vendeur sur une deuxième machine se reconnecte, et toute personne ayant ce compte système est connectée comme cette boutique. Nous avons préféré cela à un identifiant qui peut être exporté dans un package et vendu.