Ein Spiel an den Marketplace ausliefern
Ein Marketplace-Spiel ist ein Spiel, das du einmal baust und jeder einbetten kann: du veröffentlichst ein öffentliches GitHub-Repo, die Plattform indexiert es, und Nutzer erreichen es per seiner Spiel-id ohne Beteiligung von dir. Das ist das andere Ende von einem Custom-Spiel, das nur du nutzen kannst und das du selbst hostest. Dieser Abschnitt ist der detaillierte Bau-und-Veröffentlich-Leitfaden zum Marketplace-Weg.
Willst du nur ein Spiel für deine eigenen Site-Keys, willst du stattdessen Custom-Spiel-Entwicklung. Komm hierher, wenn du ein Spiel an jeden Caputchin-Nutzer verteilen willst.
Die ganze Pipeline
Jede Box bildet eine Seite in diesem Abschnitt ab:
| Stück | Was es ist | Seite |
|---|---|---|
| Das Spiel | Ein in sich geschlossenes JS-Bundle, gebaut gegen das Spiel-SDK, das im gesandboxten Iframe des Widgets läuft. | Ein Marketplace-Spiel bauen, SDK-Referenz |
| Das Manifest | Eine caputchin.json im Repo-Root, die das Spiel, seine Presets und sein Bundle beschreibt. | Das caputchin.json-Manifest |
| Der Replay-Vertrag | Ein deterministisches run(seed, trace) -> verdict, das der Server erneut laufen lässt, um zur maßgeblichen Entscheidung zu kommen. | Der Replay-Vertrag |
| Das Engine-Kit | Ein optionales Verfassungs-Kit, das ein konformes run aus einem schlichten Reducer produziert. | Das engine-kit |
| Veröffentlichen | Das Repo taggen, der Indexer entdeckt und pinnt es, optional mit CI automatisieren. | An den Marketplace veröffentlichen |
Abspielbar gegen nicht abspielbar
Die einzelne wichtigste Idee auf diesem Weg: ein Marketplace-Spiel kann Verifizierung nur gaten, wenn es serverseitig abspielbar ist. Wenn der Indexer dein Spiel aufnimmt, lässt er eine Replay-Selbstprüfung laufen: er lädt dein Headless-run-Artefakt in ein versiegeltes Isolate und bestätigt, dass es ein gültiges Urteil produziert.
- Selbstprüfung besteht → das Spiel ist abspielbar: die Runde eines echten Spielers wird auf dem Server erneut gelaufen, um zur Entscheidung zu kommen, sodass das Spiel einen Site-Key gaten kann.
- Selbstprüfung schlägt fehl → das Spiel zeigt sich als Nicht abspielbar. Es ist trotzdem gelistet und trotzdem einbettbar, aber nur als UX (kein Sicherheits-Gate), bis du eine Version veröffentlichst, die besteht. Seiten, die schon auf einer früheren abspielbaren Version sind, lassen genau diesen Snapshot weiterlaufen.
Deshalb ist Determinismus kein optionaler Feinschliff: er ist die Linie zwischen einem Spiel, das einen Site-Key bewachen kann, und einem, das bloß dekorativ ist.
Wie sich ein Marketplace-Spiel von einem Custom-Spiel unterscheidet
| Marketplace-Spiel | Custom-Spiel | |
|---|---|---|
| Wer es einbetten kann | Jeder, per Spiel-id | Nur du |
| Hosting | Plattform-gepinnt aus deinem GitHub / npm | Du hostest das Bundle (game-src) |
| Anpassungs-Schema | In caputchin.json deklariert | Im Dashboard deklariert |
| Replay-Artefakt | Aus dem run des Manifests indexiert | Im Dashboard hochgeladen |
| Entdeckung | Durchstöberbarer Marketplace | Keine |
Wo anfangen
Hast du nie ein Caputchin-Spiel gebaut, lies Ein Marketplace-Spiel bauen von oben bis unten, dann Der Replay-Vertrag. Wenn du bereit bist auszuliefern, folg An den Marketplace veröffentlichen. Das Engine-Kit ist optional und kann ganz übersprungen werden.
Siehe auch
- Ein Marketplace-Spiel bauen: das Bau-Tutorial.
- Der Replay-Vertrag: was ein Spiel abspielbar macht.
- An den Marketplace veröffentlichen: taggen, indexieren, automatisieren.
- Custom-Spiel-Entwicklung: die selbst-gehostete, nur-deine-Keys-Alternative.