Publier au marketplace

À la fin de ce tutoriel, ton jeu est listé dans le marketplace et intégrable par n'importe quel utilisateur, par son id de jeu. La publication est intentionnellement peu cérémonieuse : il n'y a pas de file de soumission, pas de revue, et pas de téléversement. Tu tagues un dépôt GitHub public et la plateforme l'indexe.

Ceci suppose que tu as bâti un jeu (Bâtir un jeu pour le marketplace) et écrit son manifeste.

1. Tague le dépôt GitHub

Ajoute le topic GitHub caputchin-game à ton dépôt public (la section About sur la page du dépôt). L'indexeur interroge GitHub pour ce topic ; ce tag est tout ton opt-in.

Ton id de jeu est dérivé de la coordonnée du dépôt, owner/repo (ou owner/repo/<leaf-dir> pour un enfant de collection). Tu ne le choisis ni ne le déclares.

2. Confirme les essentiels du manifeste

Trois choses conditionnent l'indexation ; assure-toi que ton caputchin.json racine les a :

1. "terms_accepted": true (le booléen littéral) confirmant les Conditions de soumission au Marketplace.
2. Une license sur la liste approuvée.
3. Un pointeur de distribution (entry, npm, ou les deux) pour que le bundle se résolve.

Ajoute un marketplace.author.email si tu veux les e-mails d'échec de publication (il n'est jamais montré publiquement, et c'est le seul moyen de les recevoir).

3. Publier ou mettre à jour

Deux façons d'atterrir dans l'index :

• Le cron quotidien ramasse automatiquement les dépôts tagués.
• Le bouton « Publier ou mettre à jour » sur le marketplace exécute l'indexeur par dépôt de façon synchrone et te redirige vers ta page de détail, ou montre l'erreur de validation exacte. Utilise ceci pour un premier listing ou juste après une modification de manifeste.

Quand il s'exécute, l'indexeur récupère ton manifeste, épingle le bundle à une ref immuable (la version npm publiée ou le SHA de commit résolu), calcule un hash d'intégrité SHA-384, et stocke { url, integrity } clé par ton id de jeu. Les nouvelles releases passent en ligne au prochain passage d'indexation, ou instantanément via le bouton.

4. L'auto-vérification de rejeu

Au moment de l'indexation, la plateforme exécute ton artefact run dans un isolat scellé une fois avec une graine déterministe :

• Réussit → ton jeu est rejouable : la manche d'un vrai joueur est réexécutée côté serveur pour atteindre la décision, donc il peut gater une clé de site.
• Échoue (run-not-conforming) → le jeu s'affiche Non rejouable. Il est toujours listé et intégrable, mais seulement comme UX jusqu'à ce que tu publies une version conforme. Les sites déjà sur une version rejouable antérieure continuent d'exécuter cet instantané exact.

Une auto-vérification échouée est presque toujours du non-déterminisme dans ton run ; rends ta simulation déterministe et republie. Exécuter le selfCheck du kit moteur en local d'abord attrape ça avant que tu pousses.

5. Vérifie la découverte

Après une publication réussie, la page de détail intègre ton jeu dans un aperçu en direct avec une molette pour chaque préréglage de locale, de skin et de configuration déclaré. Joue-le là pour confirmer que les préréglages se résolvent comme tu l'as voulu.

Sois notifié quand une publication échoue

L'indexeur quotidien revérifie chaque jeu publié. Si une réindexation rencontre un problème, tu peux en être informé par e-mail, mais seulement si tu optes en réglant marketplace.author.email dans ton manifeste. Sans e-mail réglé, tu n'obtiens aucune notification. Il n'y a pas d'autre canal ; c'est l'unique signal que tu manquerais autrement, parce que la revérification quotidienne tourne sans que tu surveilles.

Deux genres d'e-mail sont envoyés, correspondant aux deux résultats :

Détails qui comptent :

• Seule la réindexation quotidienne t'envoie un e-mail. Un échec sur le bouton manuel « Publier ou mettre à jour » t'est montré dans la modale à ce moment-là, donc aucun e-mail n'est envoyé pour ça.
• Dédupliqué. Le même échec sur le même jeu est envoyé une fois par e-mail, puis supprimé pendant 30 jours. Un échec différent (un nouveau code d'erreur ou une nouvelle raison) envoie un e-mail immédiatement.
• Désinscris-toi à tout moment en retirant ou changeant marketplace.author.email. Les e-mails portent aussi un pointeur de désinscription en un clic vers les Conditions de soumission. Tu n'es pas un compte Caputchin ici, donc le champ du manifeste est le seul contrôle.

6. Automatise avec la CI

Parce que publier est « taguer plus pousser vers une ref immuable », tu peux le câbler dans ton pipeline de release pour que chaque release se réindexe automatiquement. Le schéma fiable :

1. Publie le bundle vers une ref immuable en CI, le publish npm (ou une release GitHub taguée) contre lequel le npm / entry de ton manifeste se résout. L'indexeur re-résout toujours vers ta dernière version publiée à son prochain passage, donc un pipeline de release normal avance déjà l'épingle.
2. Conditionne la release à une vérification de déterminisme locale. Exécute le selfCheck du kit moteur (ou ton propre test de rejeu) comme étape CI pour qu'un run non déterministe fasse échouer le build au lieu de livrer comme non rejouable.
3. Déclenche optionnellement une réindexation immédiate en appelant « Publier ou mettre à jour » plutôt qu'attendre le cron quotidien, si tu veux la nouvelle version en ligne dès que la CI finit.

# sketch: release job
- run: npm ci
- run: npm test                 # includes your replay selfCheck
- run: npm publish              # advances the immutable ref the indexer pins
# the daily indexer picks up the new version; or hit Publish or update for instant

Garde la vérification de déterminisme avant la publication pour qu'un mauvais run n'atteigne jamais le marketplace comme un listing silencieusement non rejouable.

Ce que tu n'as jamais à faire

• Pas de signature de code, pas de soumission à revue, pas de téléversement vers le CDN de la plateforme.
• Pas d'accord de partage de revenus.
• Pas de choix d'id ; ta coordonnée GitHub est l'id.
• Pas de champ de version ; l'indexeur épingle la ref.

Si la publication échoue

Chaque erreur du chemin de publication est quelque chose que tu corriges dans ton dépôt et réessaies. Trouve ton code dans Corriger un échec de publication ; la liste complète des codes est la référence des erreurs de publication.

Voir aussi

• Corriger un échec de publication : corrections pas à pas par code d'erreur.
• Le manifeste caputchin.json : les champs que l'indexeur valide.
• Le contrat de rejeu : ce que l'auto-vérification exécute.