phaser-release

Phaser 4 ゲームのリリース

ビルドをホストに載せるところまでは簡単で、skills/phaser-build/ がすでにそれを扱っています。このスキルはその残りを扱います。ゲームをリリースする準備ができているかの判断、実際に遊んでもらえる形での見せ方、そしてローンチ後の運用ループです。

最もよくあるリリースの失敗は、壊れたビルドではありません。動いてはいるものの、見せ方が悪く、その結果ゲームそのものが問題だったと結論づけてしまうことです。

---

準備完了のゲート

以下がすべて通るまで、リリース準備を始めないでください。そのどれもが、これまでローンチを終わらせてきた項目です。

# 1. Compiles
npx tsc --noEmit

# 2. Runs — as a production build, which is what players get
node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs" \
  --project . --mode build

# 3. Every scenario still passes
for f in playtest/*.mjs; do
  node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs" \
    --project . --scenario "$f" --mode build || echo "FAILED: $f"
done

# 4. Holds up on mobile if you claim mobile support
node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs" \
  --project . --mode build --device iphone

# 5. No leak across a long session
node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs" \
  --project . --scenario playtest/long-session.mjs --heap

重要なのは --mode build の方です。 開発モードは、プレイヤーにしか見えない失敗をちょうど隠してしまいます。vite.config.ts 内の誤った base パスによって itch.io 上のすべてのアセットが 404 になること、src/ から参照されているのに dist/ に届いていないアセット、.name に依存するコードをミニファイが壊すこと、動的にしか参照されていないシーンをツリーシェイキングが落としてしまうことなどです。開発環境では完璧なのにビルドでは壊れているゲームは、ローンチ当日の失敗として最もよくある単一の原因です。

ハーネスでは確認できない手動チェック

チェック	なぜ重要か
自分で最初から最後まで遊ぶ	何か見つかります。必ず見つかります。
説明なしで他の人に遊んでもらう	チュートリアルの欠落は、本当の他人がいて初めて現れます
スピーカーとヘッドホンの両方で音のバランスを確認する	片方で作ったミックスは、もう片方ではたいてい誤っています
すべての設定トグルが実際に機能する	壊れた設定は、壊れたゲームとして受け取られます
セーブがページのリロードに耐える	さらにブラウザの再起動、そしてバージョンアップにも
実機のスマートフォンで動作する	エミュレーションは Safari ではありません

他人テストはこのリストの中で最も価値の高い項目です。見守り、助けてはいけません。何かを説明したくなる瞬間のすべてが、まだ修正できる設計上の問題です。

---

バージョニング

バージョンを設定し、ゲームに組み込みます:

// Read from package.json at build time; never hand-maintain two copies.
const config: Phaser.Types.Core.GameConfig = {
  gameVersion: __APP_VERSION__,   // define in vite.config.ts
  // ...
};

// vite.config.ts
import pkg from './package.json';
export default defineConfig({
  define: { __APP_VERSION__: JSON.stringify(pkg.version) },
});

目立たない場所に表示しましょう。たとえばタイトル画面の隅です。バグ報告で「最新バージョンで起きます」と言われたとき、相手が実際に動かしていたものが何だったのかを知る必要があります。画面から読み取れるバージョンがあれば、役に立つ報告と推測の違いになります。

ゲームにおけるセマンティック風バージョニング:

上げ方	いつ
0.1.0 → 0.2.0	新しいコンテンツや機能
0.2.0 → 0.2.1	修正
0.x → 1.0.0	設計どおりにゲームが完成したとき

セーブ形式は別にバージョン管理し、最初のリリースからそうしてください:

interface SaveData { version: number; /* ... */ }

プレイヤーがセーブを持った後にこれを後付けするのは、手元にないデータに対してテストできないマイグレーションになります。skills/phaser-saveload/ を参照してください。

---

ストアページ

ほとんどの Web ゲームでは、ページは単一の機能よりもプレイ数に貢献します。それはマーケティングの飾りではなく、人々が判断を下す場所です。

必須要素、インパクトの大きい順

1. ファーストビューに GIF か短い動画。 人は読む前に見ます。タイトル画面ではなくプレイを見せるべきです。動きから始め、10 秒以内に収め、きれいにループさせましょう。
2. ゲームが何なのかを述べる一文。 ブレインストーミングで作ったフックです。「わくわくする冒険」ではなく、プレイヤーが何をするのかを。
3. 異なるものを見せるスクリーンショット。 同じ部屋の画像が 4 枚あれば、そのゲームには部屋がひとつしかないと言っているようなものです。
4. 操作説明を平易に明記。 Web ゲームのプレイヤーは探し回りません。ページとタイトル画面の両方に載せましょう。
5. 正直なボリューム。 「15 分のアーケードゲーム」は正しい期待値を設定し、ラベルなしの短いゲームよりも良い反応を得られます。

GIF の作り方

node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs" \
  --project . --scenario playtest/showcase.mjs --video --mode build

最も視覚的に面白い 10 秒を再生するシナリオを使えば、カーソルも操作ミスもない、クリーンで再現可能なキャプチャが得られます。しかもアートが変わるたびに、コマンドひとつで撮り直せます。

itch.io 固有の注意点

• dist/ の中身を zip 圧縮し、フォルダーごと圧縮しないでください。index.html が zip のルートにある必要があります。
• ビューポートの寸法をゲームに合わせて設定し、フルスクリーンを有効にしてください。
• vite.config.ts の base: './' — 絶対パスの base はすべてのアセットを 404 にします。
• タグは正確に付けてください。タグは itch がゲームを表示する仕組みであり、間違ったタグは間違ったプレイヤーを呼び込み、そのプレイヤーがレビューを書いて去っていきます。

itch.io、GitHub Pages、Netlify/Vercel、Capacitor のデプロイの仕組みについては、skills/phaser-build/SKILL.md にあります。

---

ローンチ当日

告知する前にフィードバック経路を整えてください。 誰も読んでいないコメントスレッドや、まだ存在しない Discord は、初日の報告を失わせます — これは得られる中で最も価値のある報告です。なぜなら、最も熱心とは言えないプレイヤーからのものだからです。

ゲーム内に報告手段を追加してください：

if (this.input.keyboard) {
  this.input.keyboard.on('keydown-F8', () => {
    const state = { version: __APP_VERSION__, scene: this.scene.key, /* ... */ };
    navigator.clipboard?.writeText(JSON.stringify(state));
  });
}

現在のゲーム状態をコピーするキーは、散文の一段落をプレイテストの eval ステップにそのまま貼り付けられるものに変えます。10 行で済み、バグ報告の価値が変わります。

次の順番で確認してください：

1. 他の人、他のネットワークでそもそも読み込めるか？
2. 最初の 1 分を突破できるか？ そこでの離脱は難易度ではなくオンボーディングの問題です。
3. 最初の 1 時間で何を言っているか？ 初期の報告は本当の阻害要因に偏ります。

ロールバックを用意してください。 前のビルドを保持しておきます。ローンチ当日に問題が起きた場合、2 分で復元する方が、観客の前でプレッシャーの中でデバッグするよりも優れています。

---

ローンチ後：ループ

リリースは面白い部分の始まりです。フィードバックが届き、それをより良いゲームに変えるループは次のとおりです：

/phaser-feedback   # triage, reproduce, fix, verify, reply

再現された各バグは playtest/repro-*.mjs シナリオを残し、それが次のリリースのゲートの一部になります。数回のリリースを経ると、そのスイートは実際のプレイヤーがあなたのゲームに対して実際に行ったことを記録します — これはどれだけユニットテストをしても生み出せません。skills/phaser-feedback/ を参照してください。

パッチリリース

修正を迅速かつ目に見える形で出荷してください。報告から 1 日以内に修正が届くゲームは、気にかけられていると受け取られ、その評判が次に誰かが報告するかどうかを決めます。

各パッチについて：

1. 再現シナリオとともに修正します。
2. 完全な準備ゲートをもう一度実行します — パッチは、特にプレッシャーの中で、物事を壊します。
3. パッチバージョンを上げます。
4. プレイヤー向けの変更履歴を書きます：何が変わったかを、彼らの言葉で、fixed null deref in ShopScene ではなく。skills/phaser-feedback/references/response-templates.md を参照してください。
5. 報告してくれた人に伝えます。数が許すなら個別に。

いつ止めるかを知る

残っている項目が問題ではなく改善点になったとき、ゲームは完成です。磨き上げは常にもっとあります。有用なシグナルは 2 つあります：

• しばらく阻害要因を誰も報告しておらず、残りのリストが好みの問題である。
• プレイヤーに正当化できない変更を加えている。

止めて、ポストモーテムを書き、次を始めてください。未完成のゲームは、完成したゲームよりもはるかに少ないことを教えます。そして、不満が出なくなった後も磨き続けるゲームは、作られていないゲームです。

---

追加リソース

参照ファイル

• references/release-checklist.md — チェックリスト形式の完全なゲート、プラットフォームごと、およびローンチ前、ローンチ当日、ローンチ後のシーケンス。
• references/store-presence.md — ストアページの作り方：キャプチャ、スクリーンショット、説明、タグ、および itch.io、Newgrounds、Poki、モバイルストアのプラットフォーム固有の要件。

関連

• skills/phaser-build/ — デプロイの仕組みとホストごとの設定
• skills/phaser-feedback/ — ローンチ後のループ
• skills/phaser-playtest/ — このスキルが依存するゲート
• skills/phaser-mobile/ — モバイルとストアのパッケージングの詳細
• skills/phaser-saveload/ — セーブのバージョニング。これは最初のリリース前に存在している必要があります