マーケットプレイスに公開する

このチュートリアルの終わりまでに、あなたのゲームはマーケットプレイスに一覧され、どのユーザーもそのゲーム id で埋め込めることでしょう。公開は意図的に儀式が少ないです。投稿の行列も、レビューも、アップロードもありません。公開の GitHub リポジトリにタグを付けると、プラットフォームがそれをインデックスします。

これは、ゲームを作り（マーケットプレイスゲームを作る）、そのマニフェストを書いたことを前提とします。

1. GitHub リポジトリにタグを付ける

公開のリポジトリ（リポジトリページの About セクション）に GitHub のトピック caputchin-game を追加します。インデクサーはこのトピックを GitHub に問い合わせます。そのタグがあなたのオプトインのすべてです。

あなたのゲーム id は、リポジトリの座標 owner/repo（またはコレクションの子には owner/repo/<leaf-dir>）から 導かれます。あなたが選んだり宣言したりしません。

2. マニフェストの必須事項を確認する

3 つのことがインデックスをゲートします。ルートの caputchin.json がそれらを持つことを確かめてください：

マーケットプレイス投稿規約を確認する "terms_accepted": true（リテラルのブール値）。
承認された一覧の license。
バンドルが解決されるよう、配布ポインター（entry、npm、または両方）。

公開失敗のメールが欲しいなら marketplace.author.email を追加します（決して公開されず、それを受け取る唯一の方法です）。

3. 公開または更新

インデックスに着地する 2 つの方法：

日次の cron がタグ付きのリポジトリを自動で拾います。
マーケットプレイスの 「公開または更新」ボタン は、リポジトリごとのインデクサーを同期で走らせ、あなたを詳細ページにリダイレクトするか、正確な検証エラーを示します。最初の一覧や、マニフェストの編集の直後に使ってください。

走るとき、インデクサーはあなたのマニフェストを取得し、バンドルを不変の ref に固定（公開された npm バージョンか解決されたコミット SHA）し、SHA-384 の完全性ハッシュを計算し、あなたのゲーム id をキーに { url, integrity } を保存します。新しいリリースは、次のインデックスの実行で、またはボタンで即座に本番になります。

4. リプレイのセルフチェック

インデックス時に、プラットフォームはあなたの run アーティファクトを、封じられたアイソレートで、決定論的なシードとともに一度走らせます：

通る → あなたのゲームは リプレイ可能 です。本物のプレイヤーのラウンドが決定に達するためにサーバー側で再実行されるので、サイトキーをゲートできます。
失敗する（run-not-conforming）→ ゲームは リプレイ不可 と表示されます。それでも一覧され埋め込めますが、適合するバージョンを公開するまで UX としてのみです。すでに以前のリプレイ可能なバージョンにいるサイトは、まさにそのスナップショットを走らせ続けます。

失敗するセルフチェックは、ほぼ常にあなたの run の非決定論です。シミュレーションを決定論的にして再公開してください。エンジンキットの selfCheck を先にローカルで走らせると、プッシュ前にこれを捕らえます。

5. 発見を確認する

公開の成功の後、詳細ページは、宣言された各ロケール、スキン、構成のプリセットのつまみとともに、ライブのプレビューにあなたのゲームを埋め込みます。そこでそれを遊び、プリセットが意図どおりに解決することを確認してください。

日次のインデクサーは、すべての公開済みのゲームを再チェックします。再インデックスが問題に当たると、それについてメールを受けられますが、マニフェストに marketplace.author.email を設定して オプトインした場合だけ です。メールが設定されていないと、通知を受けません。ほかのチャネルはありません。これは、さもなければ見逃すであろう唯一のシグナルです。日次の再チェックは、あなたが見ていないうちに走るからです。

2 種類のメールが送られ、2 つの結果に対応します：

メール	いつ	何を意味するか
「`<game>` の検証チェックが失敗しました」	再インデックスされたバージョンがリプレイのセルフチェック（`run-not-conforming`）に失敗	ゲームは一覧され埋め込めるままですが、そのバージョンはリプレイ不可と表示され、適合するものを公開するまでゲートできません。
「`<game>` を公開できませんでした」	再インデックスがほかの失敗（マニフェスト、ライセンス、バンドルのエラー）に当たる	そのバージョンは、直すまで一覧されません。

大事な詳細：

日次の再インデックスだけがメールします。 手動の「公開または更新」ボタンでの失敗は、そのときモーダルであなたに示されるので、それにメールは送られません。
重複排除。 同じゲームの同じ失敗は一度メールされ、それから 30 日間抑制されます。別の失敗（新しいエラーコードか理由）は即座にメールします。
いつでもオプトアウト、marketplace.author.email を取り除くか変えることで。メールは投稿規約へのワンクリックの購読解除のポインターも運びます。あなたはここで Caputchin のアカウントではないので、マニフェストのフィールドが唯一のコントロールです。

6. CI で自動化する

公開が「タグに不変の ref へのプッシュを足したもの」なので、それをリリースのパイプラインに配線して、すべてのリリースが自動で再インデックスされるようにできます。信頼できるパターン：

バンドルを不変の ref に公開する、CI で、マニフェストの npm / entry が解決する npm の publish（またはタグ付きの GitHub のリリース）です。インデクサーは次の実行で常にあなたの最新の公開バージョンに再解決するので、通常のリリースのパイプラインがすでに固定を進めます。
リリースをローカルの決定論のチェックでゲートする。 エンジンキットの selfCheck（またはあなた自身のリプレイのテスト）を CI のステップとして走らせ、非決定論的な run が、リプレイ不可として出荷されるのではなく、ビルドを失敗させるようにします。
任意で即座の再インデックスを引き起こす、日次の cron を待つのではなく「公開または更新」を呼ぶことで。新しいバージョンを CI が終わった瞬間に本番にしたいなら。

# 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

決定論のチェックを公開の前に保って、悪い run が、黙ってリプレイ不可の一覧としてマーケットプレイスに決して届かないようにしてください。

あなたが決してしなくてよいこと

コード署名なし、レビューの投稿なし、プラットフォームの CDN へのアップロードなし。
収益分配の合意なし。
id 選びなし。あなたの GitHub の座標が id です。
バージョンフィールドなし。インデクサーが ref を固定します。

公開が失敗したら

すべての公開パスのエラーは、あなたがリポジトリで直して再試行するものです。あなたのコードは公開失敗を直すで見つけてください。完全なコードの一覧は公開エラーリファレンスです。

あわせて読む

公開失敗を直す：エラーコードごとの順を追った修正。
caputchin.json マニフェスト：インデクサーが検証するフィールド。
リプレイ契約：セルフチェックが走らせるもの。