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/。

---

商店页面

对于大多数网页游戏来说，页面对游玩人数的影响胜过任何单一功能。这不是华而不实的营销内容，而是玩家做出选择的地方。

必备内容，按影响力排序

1. 首屏显示 GIF 或短视频。 玩家会先看再读。内容应该展示实际游玩画面，而不是标题画面——从动态画面开始，时长控制在 10 秒以内，并确保循环流畅。
2. 用一句话说明游戏是什么。 使用头脑风暴时提炼出的核心卖点。不要写“激动人心的冒险”，而要说明玩家要做什么。
3. 展示不同内容的截图。 四张同一房间的图片，会让人觉得游戏只有一个房间。
4. 清楚地说明操作方式。 网页游戏玩家不会费心寻找。既要放在页面上，也要放在标题画面上。
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/ 中的内容，而不是文件夹。index.html 必须位于压缩包根目录。
• 将视口尺寸设为与游戏相符，并启用全屏。
• 在 vite.config.ts 中使用 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 步骤中的内容。 只需十行代码，却能大幅提升 Bug 报告的价值。

按以下顺序关注：

1. 其他人能否在其他网络环境下成功加载游戏？
2. 玩家能否玩过第一分钟？如果玩家在这里流失，问题出在新手引导，而不是难度。
3. 发布后一小时内，玩家都说了什么？早期反馈往往更集中于真正的阻碍。

准备好回滚方案。 保留上一个构建版本。如果发布日出了问题，两分钟内恢复要胜过在观众面前顶着压力调试。

---

发布之后：循环

发布才是精彩部分的开始。反馈会陆续到来，而将反馈转化为更好游戏的循环是：

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

每个复现的 Bug 都会留下一个 playtest/repro-*.mjs 场景，并成为下一次发布的准入检查项。经过几次发布后，这套测试就会记录真实玩家实际如何游玩你的游戏——这是再多的单元测试也无法做到的。参见 skills/phaser-feedback/。

补丁版本

快速、明确地发布修复。报告提交后一天内就修复的游戏，会给人以重视玩家反馈的印象；这种口碑决定了玩家是否愿意继续报告问题。

每次发布补丁时：

1. 修复问题，并编写复现场景。
2. 再次运行完整的就绪检查——补丁也会引入问题，尤其是在压力之下。
3. 提升补丁版本号。
4. 撰写面向玩家的更新日志：用玩家能理解的说法说明改动，而不是写成 fixed null deref in ShopScene。参见 skills/phaser-feedback/references/response-templates.md。
5. 告知报告问题的玩家。如果人数允许，逐一告知。

了解何时该停止

当剩余事项都是改进而非问题时，游戏就完成了。总有更多细节可以打磨。以下是两个有用的信号：

• 有一段时间没人报告阻碍性问题，剩下的都是偏好问题。
• 你正在做一些无法向玩家解释的改动。

停下来，写好复盘，然后开始下一个游戏。未完成的游戏教会你的东西远不如完成的游戏多；而打磨到没人再抱怨的游戏，也意味着你已经没在制作游戏了。

---

其他资源

参考文件

• 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/ —— 存档版本管理，必须在首次发布前完成