Dein eigenes Spiel betreiben
Ein Custom-Spiel ist ein Spiel, das du baust und hostest, im Caputchin-Widget genutzt statt eines Marketplace-Spiels. Niemand sonst kann es installieren, es gibt kein GitHub-Topic und keinen Publish-Schritt, und du behältst den Code. Dieser Abschnitt ist der detaillierte Bau-es-selbst-Leitfaden zu diesem Weg. (Willst du ein Spiel ausliefern, das jeder einbetten kann, ist das Marketplace-Spiel-Entwicklung, ein separater Weg.)
Es gibt zwei Wege, ein Custom-Spiel auszuliefern, und sie sind wirklich verschiedene Flächen mit verschiedenen Grenzen. Wähl danach, was du brauchst:
Manueller Modus: dein eigenes DOM, kein Gate
Manueller Modus ist die leichtgewichtige Option. Du setzt trigger="manual" auf <caputchin-game>, legst dein eigenes Markup hinein und rufst die Methoden pass() / fail() des Elements aus deinem eigenen Code, wenn der Besucher gewinnt oder verliert. Es gibt keinen Iframe und kein Spiel-SDK; das Widget gibt dir nur seine Layout-Hülle und die Verifizierungs-Verrohrung um dein Markup.
Der Kompromiss: eine Runde im manuellen Modus kann nicht server-abgespielt werden, also kann ein Spiel im manuellen Modus kein Spiel-Gate erfüllen. Es läuft nur auf einem ungegateten Key (Proof-of-Work-Verifizierung, mit deiner Interaktion als UX), oder nur als Spiel ganz ohne Verifizierung. Nimm es für eine gebrandete Interaktion, nicht für ein Sicherheits-Gate, das du abgespielt brauchst.
Selbst gehostetes Iframe-Spiel: kann gaten
Ein selbst gehostetes Spiel ist ein echtes, gesandboxtes Spiel: ein JavaScript-Bundle, gebaut gegen das @caputchin/game-sdk-Paket, das im Iframe des Widgets läuft, mit dem Host über die SDK-Brücke spricht und einen Trace meldet, den der Server erneut laufen lassen kann. Du hostest das Bundle selbst und richtest das Widget mit dem game-src-Attribut darauf.
Weil die Runde einen abspielbaren Trace produziert, kann ein selbst gehostetes Spiel einen Site-Key gaten, aber erst, wenn du Caputchin ein Replay-Artefakt gibst: einen kleinen Headless-Build deiner Spiel-Logik, den der Server ausführt, um das Urteil neu abzuleiten. Bis dieses Artefakt hochgeladen ist und seine Selbstprüfung besteht, zeigt sich das Custom-Spiel als Nicht abspielbar und kann nicht gaten.
Was das Dashboard hinzufügt
Ein Marketplace-Spiel liefert ein caputchin.json-Manifest, das seine Anpassungs-Felder deklariert. Ein Custom-Spiel hat kein Manifest, also deklarierst du diese Felder stattdessen im Dashboard: du registrierst das Custom-Spiel per einer id, die du wählst, definierst sein Feld-Schema pro Achse (Sprache, Skin, Konfiguration) und verfasst Presets dagegen. Von dort löst es sich auf und wird genau wie ein Marketplace-Spiel angewendet, auf denselben Tarifstufen.
Die vollständige Custom-Spiel-Fläche ist also:
| Teil | Wo | Gebraucht für |
|---|---|---|
| Das Spiel selbst | Dein Code, dein Host | Immer |
| Auslieferung | trigger="manual"-Slot oder game-src-Iframe | Immer |
| Feld-Schema + Presets | Dashboard (du definierst das Schema) | Anpassung von Sprache / Skin / Config |
| Replay-Artefakt | Dashboard-Upload | Verifizierung gaten (nur selbst gehostet) |
Siehe auch
- Manueller Modus: dein eigenes DOM slotten und pass/fail treiben.
- Selbst gehostetes Spiel: ein abspielbares Iframe-Spiel mit dem SDK bauen.
- Replay und Gating: das Artefakt hochladen, das ein Custom-Spiel gaten lässt.
- Dashboard-Schema-Referenz: das Feld-Schema, das du für ein Custom-Spiel definierst.
- Custom-Spiele: registrieren und hosten, von der Kundenseite.