Exécute ton propre jeu
Un jeu personnalisé est un jeu que tu bâtis et héberges, utilisé dans le widget Caputchin à la place d'un jeu du marketplace. Personne d'autre ne peut l'installer, il n'y a pas de topic GitHub ni d'étape de publication, et tu gardes le code. Cette section est le guide détaillé, fais-le-toi-même, de ce chemin. (Si tu veux livrer un jeu que n'importe qui peut intégrer, c'est le développement de jeu pour le marketplace, un chemin distinct.)
Il y a deux façons de livrer un jeu personnalisé, et ce sont véritablement des surfaces différentes avec des limites différentes. Choisis selon ce dont tu as besoin :
Mode manuel : ton propre DOM, pas de gate
Le mode manuel est l'option légère. Tu règles trigger="manual" sur <caputchin-game>, mets ton propre balisage dedans, et appelles les méthodes pass() / fail() de l'élément depuis ton propre code quand le visiteur réussit ou échoue. Il n'y a pas d'iframe ni de SDK de jeu ; le widget te donne juste son shell de mise en page et la plomberie de vérification autour de ton balisage.
Le compromis : une manche en mode manuel ne peut pas être rejouée par le serveur, donc un jeu en mode manuel ne peut pas satisfaire un gate de jeu. Il ne tourne que sur une clé non gatée (vérification par proof of work, avec ton interaction comme UX), ou en jeu-seul sans aucune vérification. Utilise-le pour une interaction de marque, pas pour un gate de sécurité que tu as besoin de faire rejouer.
Jeu auto-hébergé en iframe : peut gater
Un jeu auto-hébergé est un vrai jeu en bac à sable : un bundle JavaScript bâti contre le paquet @caputchin/game-sdk qui tourne dans l'iframe du widget, parle à l'hôte via le pont du SDK, et rapporte une trace que le serveur peut rejouer. Tu héberges le bundle toi-même et pointes le widget vers lui avec l'attribut game-src.
Parce que la manche produit une trace rejouable, un jeu auto-hébergé peut gater une clé de site, mais seulement une fois que tu donnes à Caputchin un artefact de rejeu : un petit build headless de ta logique de jeu que le serveur exécute pour re-dériver le verdict. Tant que cet artefact n'est pas téléversé et ne réussit pas son auto-vérification, le jeu personnalisé s'affiche Non rejouable et ne peut pas gater.
Ce qu'ajoute le tableau de bord
Un jeu du marketplace livre un manifeste caputchin.json qui déclare ses champs de personnalisation. Un jeu personnalisé n'a pas de manifeste, donc tu déclares ces champs sur le tableau de bord à la place : tu enregistres le jeu personnalisé par un id que tu choisis, définis son schéma de champs par axe (langue, skin, configuration), et rédiges des préréglages contre lui. À partir de là, il se résout et s'applique exactement comme un jeu du marketplace, aux mêmes niveaux d'offre.
Donc la surface complète du jeu personnalisé est :
| Pièce | Où | Nécessaire pour |
|---|---|---|
| Le jeu lui-même | Ton code, ton hôte | Toujours |
| Livraison | Slot trigger="manual", ou iframe game-src | Toujours |
| Schéma de champs + préréglages | Tableau de bord (tu définis le schéma) | Personnaliser langue / skin / config |
| Artefact de rejeu | Téléversement au tableau de bord | Gater la vérification (auto-hébergé seulement) |
Voir aussi
- Mode manuel : place ton propre DOM et pilote pass/fail.
- Jeu auto-hébergé : bâtir un jeu en iframe rejouable avec le SDK.
- Rejeu et gating : téléverser l'artefact qui laisse un jeu personnalisé gater.
- Référence du schéma du tableau de bord : le schéma de champs que tu définis pour un jeu personnalisé.
- Jeux personnalisés : enregistrement et hébergement, du côté client.