An den Marketplace veröffentlichen

Am Ende dieses Tutorials ist dein Spiel im Marketplace gelistet und von jedem Nutzer einbettbar, per seiner Spiel-id. Veröffentlichen ist bewusst zeremonien-arm: es gibt keine Einreichungsschlange, keine Prüfung und keinen Upload. Du taggst ein öffentliches GitHub-Repo, und die Plattform indexiert es.

Das setzt voraus, dass du ein Spiel gebaut (Ein Marketplace-Spiel bauen) und sein Manifest geschrieben hast.

1. Das GitHub-Repository taggen

Füg das GitHub-Topic caputchin-game zu deinem öffentlichen Repository hinzu (der About-Abschnitt auf der Repo-Seite). Der Indexer fragt GitHub nach diesem Topic ab; dieser Tag ist dein ganzes Opt-in.

Deine Spiel-id wird aus der Repo-Koordinate abgeleitet, owner/repo (oder owner/repo/<leaf-dir> für ein Sammlungs-Kind). Du wählst oder deklarierst sie nicht.

2. Die Manifest-Essentials bestätigen

Drei Dinge gaten die Indexierung; stell sicher, dass deine Root-caputchin.json sie hat:

1. "terms_accepted": true (das literale Boolean), das die Marketplace-Einreichungsbedingungen bestätigt.
2. Eine license auf der genehmigten Liste.
3. Ein Distributions-Zeiger (entry, npm oder beide), sodass das Bundle auflöst.

Füg ein marketplace.author.email hinzu, wenn du Publish-Fehler-E-Mails willst (es wird nie öffentlich gezeigt, und es ist der einzige Weg, sie zu empfangen).

3. Veröffentlichen oder aktualisieren

Zwei Wege, im Index zu landen:

• Der tägliche Cron nimmt getaggte Repos automatisch auf.
• Der "Veröffentlichen oder aktualisieren"-Button im Marketplace lässt den Pro-Repo-Indexer synchron laufen und leitet dich auf deine Detail-Seite, oder zeigt den genauen Validierungsfehler. Nutz das für eine erste Listung oder direkt nach einer Manifest-Bearbeitung.

Wenn er läuft, holt der Indexer dein Manifest, pinnt das Bundle auf eine unveränderliche Ref (die veröffentlichte npm-Version oder die aufgelöste Commit-SHA), berechnet einen SHA-384-Integritäts-Hash und speichert { url, integrity }, verschlüsselt nach deiner Spiel-id. Neue Releases gehen beim nächsten Index-Lauf live, oder sofort per Button.

4. Die Replay-Selbstprüfung

Zur Index-Zeit lässt die Plattform dein run-Artefakt einmal in einem versiegelten Isolate mit einem deterministischen Seed laufen:

• Besteht → dein Spiel ist abspielbar: die Runde eines echten Spielers wird serverseitig erneut gelaufen, um zur Entscheidung zu kommen, sodass es einen Site-Key gaten kann.
• Schlägt fehl (run-not-conforming) → das Spiel zeigt sich als Nicht abspielbar. Es ist trotzdem gelistet und einbettbar, aber nur als UX, bis du eine konforme Version veröffentlichst. Seiten, die schon auf einer früheren abspielbaren Version sind, lassen genau diesen Snapshot weiterlaufen.

Eine fehlschlagende Selbstprüfung ist fast immer Nicht-Determiniertheit in deinem run; mach deine Simulation deterministisch und veröffentlich erneut. Den selfCheck des Engine-Kits zuerst lokal zu laufen fängt das, bevor du pushst.

5. Entdeckung verifizieren

Nach einem erfolgreichen Veröffentlichen bettet die Detail-Seite dein Spiel in eine Live-Vorschau ein, mit einem Regler für jedes deklarierte Locale-, Skin- und Konfigurations-Preset. Spiel es dort, um zu bestätigen, dass die Presets sich wie beabsichtigt auflösen.

Benachrichtigt werden, wenn ein Veröffentlichen fehlschlägt

Der tägliche Indexer prüft jedes veröffentlichte Spiel erneut. Trifft ein Re-Index auf ein Problem, kannst du darüber gemailt werden, aber nur, wenn du dich einklinkst, indem du marketplace.author.email in deinem Manifest setzt. Ohne gesetzte E-Mail bekommst du keine Benachrichtigungen. Es gibt keinen anderen Kanal; das ist das eine Signal, das du sonst verpassen würdest, weil die tägliche Neuprüfung läuft, ohne dass du zuschaust.

Zwei Arten E-Mail werden gesendet, passend zu den zwei Ergebnissen:

Details, die zählen:

• Nur der tägliche Re-Index mailt dich. Ein Versagen am manuellen "Veröffentlichen oder aktualisieren"-Button wird dir direkt im Modal gezeigt, also wird dafür keine E-Mail gesendet.
• Dedupliziert. Dasselbe Versagen am selben Spiel wird einmal gemailt, dann 30 Tage unterdrückt. Ein anderes Versagen (ein neuer Error-Code oder Grund) mailt sofort.
• Jederzeit Opt-out, indem du marketplace.author.email entfernst oder änderst. Die E-Mails tragen auch einen Ein-Klick-Abmelde-Zeiger zu den Einreichungsbedingungen. Du bist hier kein Caputchin-Konto, also ist das Manifest-Feld die einzige Steuerung.

6. Mit CI automatisieren

Weil Veröffentlichen "taggen plus auf eine unveränderliche Ref pushen" ist, kannst du es in deine Release-Pipeline verdrahten, sodass jedes Release automatisch neu indexiert. Das verlässliche Muster:

1. Veröffentlich das Bundle auf eine unveränderliche Ref in CI, das npm-publish (oder ein getaggtes GitHub-Release), gegen das das npm / entry deines Manifests auflöst. Der Indexer löst beim nächsten Lauf immer auf deine neueste veröffentlichte Version neu auf, also rückt eine normale Release-Pipeline den Pin schon vor.
2. Gate das Release an einer lokalen Determinismus-Prüfung. Lass den selfCheck des Engine-Kits (oder deinen eigenen Replay-Test) als CI-Schritt laufen, sodass ein nicht-deterministisches run den Build fehlschlagen lässt, statt als nicht abspielbar auszuliefern.
3. Lös optional einen sofortigen Re-Index aus, indem du "Veröffentlichen oder aktualisieren" aufrufst, statt auf den täglichen Cron zu warten, wenn du die neue Version live haben willst, sobald CI fertig ist.

# 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

Halt die Determinismus-Prüfung vor dem Veröffentlichen, sodass ein schlechtes run den Marketplace nie als still nicht-abspielbare Listung erreicht.

Was du nie tun musst

• Kein Code-Signing, keine Prüfungs-Einreichung, kein Plattform-CDN-Upload.
• Keine Umsatzbeteiligungs-Vereinbarung.
• Kein id-Wählen; deine GitHub-Koordinate ist die id.
• Kein Versions-Feld; der Indexer pinnt die Ref.

Wenn das Veröffentlichen fehlschlägt

Jeder Publish-Pfad-Fehler ist etwas, das du in deinem Repo behebst und erneut versuchst. Find deinen Code in Ein Publish-Versagen beheben; die vollständige Code-Liste ist die Publish-Fehler-Referenz.

Siehe auch

• Ein Publish-Versagen beheben: Schritt-für-Schritt-Fixes nach Error-Code.
• Das caputchin.json-Manifest: die Felder, die der Indexer validiert.
• Der Replay-Vertrag: was die Selbstprüfung laufen lässt.