phaser-release

用途

本技能用于指导 Phaser 4 游戏的发布工作。资料指出，把构建产物上传到主机是容易的部分，已由 skills/phaser-build/ 覆盖；本技能覆盖其余内容：判断游戏是否已准备好发布、如何呈现以吸引玩家试玩，以及上线后的迭代循环。资料强调，最常见的发布错误并不是构建损坏，而是发布了一个能运行但呈现很差的作品，然后误以为问题出在游戏本身。

发布就绪门禁

资料要求在为发布做准备之前，以下各项必须全部通过：

编译通过：npx tsc --noEmit
以生产构建运行——因为玩家拿到的就是生产构建：

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

每个场景仍然通过：

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

若声称支持移动端，需在移动端成立：

node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs" \
  --project . --mode build --device iphone

长时间游戏会话中无泄漏：

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 的代码；tree-shaking 丢弃仅被动态引用的场景。在开发模式下完美、在生产构建中损坏，是最常见的上线日故障。

自动化无法完成的人工检查

资料以表格列出：自己从头到尾玩一遍（总能发现问题）；让另外一个人在没有说明的情况下玩（教程缺口只有在真正的陌生人身上才会出现）；在扬声器和耳机上检查音频平衡（只在一种设备上做的混音通常在另一种上是错的）；每个设置开关都真正有效（设置损坏会被读成游戏损坏）；存档在页面刷新后仍然存在（以及浏览器重启和版本号提升后）；在真机上可用（模拟不等于 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) },
});

并将其显示在不显眼的位置——例如标题画面的一角。当 bug 报告说「在最新版本上出现」时，你需要知道他们实际运行的版本；玩家能从屏幕上读出的版本号，决定了一份报告是有用的还是靠猜。

类语义化版本规则：0.1.0 → 0.2.0（新内容或功能）；0.2.0 → 0.2.1（修复）；0.x → 1.0.0（游戏按设计完成）。

存档格式要单独版本化，并且从第一次发布就要做：

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

资料指出，在玩家已经有存档之后再补做这件事，会变成一次无法用你手上没有的数据来测试的迁移。参见 skills/phaser-saveload/。

商店页面

资料认为，对大多数网页游戏而言，商店页面比任何单个功能都更能带动游玩数——它不是营销空话，而是人们做决定的地方。按影响力排序的要点：

首屏上方放 GIF 或短视频。人们先看再读。应展示玩法而非标题画面——从动作开始，控制在 10 秒以内，循环干净。
一句话说明游戏是什么。用构思阶段的钩子，不是「一段激动人心的冒险」，而是玩家做什么。
截图要展示不同内容。四张同一个房间的图等于告诉别人这游戏只有一个房间。
直白说明操作方式。网页游戏玩家不会自己去找，把操作放在页面上和标题画面上。
诚实说明体量。「一个 15 分钟的街机游戏」能设定正确预期，比不标注的短游戏反响更好。

制作 GIF 的命令：

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

资料说明，一个播放最具视觉吸引力 10 秒的场景，能给出干净、可复现的捕捉，没有光标、没有失误输入，而且美术变化后可用一条命令重新录制。

itch.io 要点：打包 dist/ 的内容而不是文件夹本身，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));
  });
}

资料称，一个复制当前游戏状态的按键能把一段散文变成可直接粘贴进 playtest eval 步骤的东西，只需十行代码，却改变 bug 报告的价值。

按顺序观察：其他人、在其他网络上是否至少能加载？人们能否通过第一分钟（此处的流失属于引导问题，而非难度问题）？第一小时他们说了什么（早期报告偏向真实阻塞问题）？同时准备好回滚：保留上一个构建，若上线日出问题，两分钟内恢复，胜过在观众面前压力下调试。

上线之后：循环

资料指出，发布才是有趣部分的开始，把反馈变成更好游戏的循环是：

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

每个复现的 bug 都会留下一个 playtest/repro-*.mjs 场景，它成为下一次发布的门禁的一部分。经过几次发布，这套测试会编码真实玩家对你游戏做过的事——这是任何数量的单元测试都产生不了的。参见 skills/phaser-feedback/。

补丁发布：快速且可见地发布修复。一份报告后一天内就修复的游戏会被读作被在意，而这种声誉决定是否还有人愿意报告下一个问题。每次补丁的流程：修复并附带复现场景；再次运行完整的就绪门禁（补丁会破坏东西，尤其在压力下）；提升补丁版本号；写面向玩家的变更日志——用玩家的话说明改了什么，而不是「fixed null deref in ShopScene」，参见 skills/phaser-feedback/references/response-templates.md；告知报告问题的人，如果数量允许，逐个通知。

知道何时停止

资料认为，当剩余条目是改进而不是问题时，游戏就算完成了。总有更多打磨空间。两个有用信号：一段时间没人报告阻塞问题，剩余清单是偏好选项；你正在做无法向玩家说明理由的修改。此时应停止，写复盘，开始下一个项目。未完成的游戏教给你的远少于完成的游戏，而打磨到超出抱怨程度的游戏，是一个不再被制作的游戏。

附加资源

引用文件：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/（存档版本化，必须在首次发布前存在）。