Livre un jeu au marketplace
Un jeu du marketplace est un jeu que tu bâtis une fois et que n'importe qui peut intégrer : tu publies un dépôt GitHub public, la plateforme l'indexe, et les utilisateurs l'atteignent par son id de jeu sans aucune implication de ta part. C'est l'extrémité opposée d'un jeu personnalisé, que toi seul peux utiliser et que tu héberges toi-même. Cette section est le guide détaillé, bâtis-et-publie, du chemin du marketplace.
Si tu veux seulement un jeu pour tes propres clés de site, tu veux plutôt le développement de jeu personnalisé. Viens ici quand tu veux distribuer un jeu à chaque utilisateur Caputchin.
Tout le pipeline
Chaque boîte correspond à une page de cette section :
| Pièce | Ce que c'est | Page |
|---|---|---|
| Le jeu | Un bundle JS autonome bâti contre le SDK de jeu qui tourne dans l'iframe en bac à sable du widget. | Bâtir un jeu pour le marketplace, référence du SDK |
| Le manifeste | Un caputchin.json à la racine du dépôt décrivant le jeu, ses préréglages et son bundle. | Le manifeste caputchin.json |
| Le contrat de rejeu | Un run(seed, trace) -> verdict déterministe que le serveur réexécute pour atteindre la décision faisant autorité. | Le contrat de rejeu |
| Le kit moteur | Un kit de rédaction optionnel qui produit un run conforme à partir d'un simple reducer. | L'engine-kit |
| Publication | Tague le dépôt, l'indexeur le découvre et l'épingle, automatise optionnellement avec la CI. | Publier au marketplace |
Rejouable contre non rejouable
L'idée la plus importante de ce chemin : un jeu du marketplace ne peut gater la vérification que s'il est rejouable côté serveur. Quand l'indexeur ingère ton jeu, il exécute une auto-vérification de rejeu : il charge ton artefact run headless dans un isolat scellé et confirme qu'il produit un verdict valide.
- L'auto-vérification réussit → le jeu est rejouable : la manche d'un vrai joueur est réexécutée sur le serveur pour atteindre la décision, donc le jeu peut gater une clé de site.
- L'auto-vérification échoue → le jeu s'affiche Non rejouable. Il est quand même listé et toujours intégrable, mais seulement comme UX (pas un gate de sécurité) jusqu'à ce que tu publies une version qui réussit. Les sites déjà sur une version rejouable antérieure continuent d'exécuter cet instantané exact.
C'est pourquoi le déterminisme n'est pas un raffinement optionnel : c'est la ligne entre un jeu qui peut garder une clé de site et un qui est simplement décoratif.
En quoi un jeu du marketplace diffère d'un jeu personnalisé
| Jeu du marketplace | Jeu personnalisé | |
|---|---|---|
| Qui peut l'intégrer | N'importe qui, par id de jeu | Toi seul |
| Hébergement | Épinglé par la plateforme depuis ton GitHub / npm | Tu héberges le bundle (game-src) |
| Schéma de personnalisation | Déclaré dans caputchin.json | Déclaré sur le tableau de bord |
| Artefact de rejeu | Indexé depuis le run du manifeste | Téléversé sur le tableau de bord |
| Découverte | Marketplace parcourable | Aucune |
Par où commencer
Si tu n'as jamais bâti de jeu Caputchin, lis Bâtir un jeu pour le marketplace de haut en bas, puis Le contrat de rejeu. Quand tu es prêt à livrer, suis Publier au marketplace. Le kit moteur est optionnel et peut être entièrement sauté.
Voir aussi
- Bâtir un jeu pour le marketplace : le tutoriel de construction.
- Le contrat de rejeu : ce qui rend un jeu rejouable.
- Publier au marketplace : taguer, indexer, automatiser.
- Développement de jeu personnalisé : l'alternative auto-hébergée, tes-clés-seulement.