game-launch

AlterLab GameForge —— 发布前上线流程

“已完成”和“已上线”之间的距离，比大多数团队预想的更长。“已上线”和“持续运营”之间的距离则更长。即使一款游戏功能齐全、没有 Bug、也很有趣，仍可能因为商店页面未优化、缺少媒体资料包、未提交年龄评级申请，或首日补丁流程未经测试而失败。更糟的是，一款游戏即使上线顺利，也可能在第二周因缺少上线后策略而销声匿迹。

《Hades》并非在上线当天就成为文化现象。它通过精心规划补丁节奏，经历了 18 个月的抢先体验，才成为文化现象。《星露谷物语》也没有止步于 1.0——ConcernedApe 的免费内容更新打造了一个至今仍在游玩的社区，八年过去依然如此。本工作流涵盖两方面：详尽的上线前流程，以及决定游戏能否熬过第一周的上线后运营。

目的与触发条件

在以下情况下使用本工作流：

• 游戏即将进入发布前的最后一个里程碑，需要制定结构化的上线计划
• 商店提交截止日期将近，团队需要核实所有要求是否都已满足
• 需要准备营销素材并协调各个平台
• 需要审核法律与合规要求（年龄评级、隐私政策、许可证）
• 团队需要一个用于做出是否上线决策的框架
• 正在计划软启动或抢先体验发布（流程相同，但需调整范围）
• 需要在上线日前建立上线后支持基础设施

以下情况请勿使用本工作流：

• 游戏仍在积极开发中，且有大量功能尚未完成（先完成开发）
• 你要发布的是内部试玩构建（改用 game-playtest）
• 游戏是没有商业意图的 Game Jam 作品（简化流程，只进行构建验证）

关键规则

1. 每个阶段都有门槛。 当前阶段未获签核前，不要进入下一阶段。为了节省时间而跳过阶段，正是导致上线计划崩盘的原因。《吸血鬼幸存者》发布时没有媒体资料包，仍然取得了成功——但那是 2021 年的偶然爆红，并非可复制的策略。
2. 商店页面不可或缺。 缺少截图、描述含糊不清或标签有误的商店页面，会扼杀游戏的曝光度。商店页面就是游戏给人的第一印象。应将其视为设计交付成果，而非待办事项。
3. 法律合规不是建议，而是硬性要求。 缺少年龄评级或隐私政策，可能导致游戏上线后被下架。这是完全可以避免的灾难性后果。
4. 为失败做好准备。 上线计划必须包含回滚策略。如果面对“上线出了问题怎么办？”这个问题，你的答案是“惊慌失措”，那么上线计划就不完整。
5. 首日补丁理所当然，不必觉得丢人。 从发行候选版本定稿到上线日之间，还会发现新问题。问题不是“我们是否需要补丁？”，而是“我们能多快部署补丁？”
6. 上线日是第一天，不是终点线。《死亡细胞》发布 1.0 后，在 4 年间推出了 6 次大型内容更新。《Hades》在 1.0 发布前经历了 18 个月的抢先体验补丁更新。上线后策略与上线前检查清单同样重要。
7. 参考 docs/game-design-theory.md，了解商店展示和首次用户体验中的玩家心理考量。

工作流

阶段 1：构建验证

这是最后一道技术关卡。在开始任何上线活动前，必须能够证明游戏稳定、性能良好且内容完整。 干净构建验证：

• 在一台此前从未构建过该项目的机器上，从源代码管理系统执行干净构建。这有助于发现缺失的依赖项、仅存在于本地的文件、硬编码路径和特定于环境的配置。
• 确认构建流程有文档记录且可复现。如果团队中只有一个人能完成构建，就会形成单点故障。
• 确认构建版本字符串正确，并与预期的发布版本一致。
• 如果游戏有启动器或自动更新程序，确认其指向正确的更新服务器。

自动化测试套件：

• 所有单元测试均通过：失败数为零，跳过数为零（除非有文档说明永久排除的原因）。
• 所有集成测试均通过：游戏系统之间能够正确交互。
• 所有平台特定测试均通过：每个目标平台都能构建并运行，不出现平台特定故障。
• 针对关键路径的冒烟测试：开始新游戏、存档/读档流程、所有主菜单选项、击败最终 Boss、播放制作人员名单。

性能验证：

• 在最低配置硬件上达到目标帧率。应在实际的最低配置硬件上测试，而非在降低设置的开发者工作站上测试。
• 加载时间符合预算。应测量并记录首次加载、关卡切换和重生时间。
• 完整游戏过程中，内存用量始终处于平台限制以内。进行 2 小时以上的连续游戏，并跟踪内存分配。如果内存持续增长，则说明存在内存泄漏。
• 磁盘空间用量处于平台限制以内（对主机和移动平台尤为重要）。
• 网络性能（如适用）：延迟、带宽用量、断线重连处理。

Bug 分级：

• P0 Bug 为零（导致游戏无法正常运行：崩溃、数据丢失、进度受阻）。
• P1 Bug 为零（严重问题：主要功能损坏、严重视觉故障、频繁软锁）。
• 所有 P2 Bug（中等问题）均已审查，并已修复或明确接受随版本发布，同时记录理由。
• P3 Bug（轻微问题：外观问题、边缘情况）均已归档，以供考虑纳入首日补丁。

存档/读档完整性：

• 能够正确加载在发布版本中创建的存档文件。
• 能够正确迁移来自最近公开版本的存档文件（如适用于抢先体验版本）。
• 损坏存档文件的处理：游戏能平稳恢复、不崩溃，并告知玩家。
• 云存档能在不同设备间正常同步（如适用）。

延长游戏时段测试：

• 一名团队成员使用发布版本从头到尾完整通关游戏。这有助于发现只会在长时间游戏中出现的问题：内存泄漏、累积状态损坏、因玩家的特殊选择导致的软锁。
• 录制完整游戏过程，并记录任何异常，即使是轻微异常也要记录。

**阶段 1 门槛：**所有自动化测试均通过。P0/P1 Bug 为零。目标硬件上的性能符合预算。延长游戏时段测试已完成，且未发现严重问题。

---

阶段 2：商店页面要求

每个商店页面都有特定的素材要求。素材缺失或不合规会延误提交或导致被拒。 Steam：

• 头图横幅（920x430）
• 小型横幅图（462x174）
• 主横幅图（1232x706）
• 竖版横幅图（748x896）
• 商店页面顶部使用的主视觉图（3840x1240）
• 库页面横幅图（600x900）
• 至少 5 张截图（最低 1280x720，建议 1920x1080）。这些应精选能体现核心体验的精彩时刻，而不是随意截取的游戏画面。
• 至少 1 支游戏预告片（60-90 秒，可嵌入或提供 YouTube 链接）
• 商店描述：吸引人的开场段落、功能列表、系统要求。请将其写成营销文案，而非设计文档。先突出情感体验，而不是功能列表。
• 标签选择：选择准确反映游戏内容的标签。为了提高曝光而错误标注会适得其反，因为期待 X 类型游戏的玩家可能会发现游戏其实属于 Y 类型。
• 系统要求（最低和推荐）：请在符合所述配置的实际硬件上进行测试。
• 评测／社区设置：配置讨论区、评测可见性和测试版分支设置。
• Steamworks 集成：成就、云存档、集换式卡牌（如适用）、远程同乐（如适用）。
• 「即将推出」页面应至少在发布前 2 周上线，以积累愿望单。

itch.io：

• 页面横幅图（建议 630x500）
• 至少 3 张截图
• 浏览页面使用的封面图（315x250）
• 简短描述（供浏览页面使用，1-2 句话）和完整描述（完整页面）
• 价格设置（付费、PWYW、免费）
• 上传下载文件并标注平台（Windows、macOS、Linux）
• 社区设置（评论、开发日志、论坛）

移动端——App Store（iOS）：

• App 图标（1024x1024，无透明背景，无圆角——Apple 会自动添加圆角）
• 每种受支持的设备尺寸都要提供截图（iPhone 6.7"、6.5"、5.5"；iPad Pro 12.9"、11"）
• App 预览视频（15-30 秒，可选但强烈推荐）
• App 名称（最多 30 个字符）、副标题（最多 30 个字符）、关键词（总计 100 个字符）
• App 描述（最多 4000 个字符，前 3 行至关重要，因为其余内容会隐藏在「更多」后面）
• 隐私政策 URL（必填）
• 年龄分级问卷（Apple 专有系统）
• App Store Connect 配置：价格、可用范围、App 内购买项目、订阅组
• 自 2026 年 4 月 28 日起：App 必须使用 iOS/iPadOS 26 SDK 构建。请据此规划构建流水线。
• 增强隐私披露：必须明确说明是否会与第三方 AI 服务共享个人数据。共享任何与 AI 相关的数据前，必须获得用户明确许可。
• 无障碍功能信息标签：App Store 产品页面新增的功能。开发者可在 App Store Connect 中填写无障碍支持信息。请准确填写——这有助于关注无障碍体验的玩家发现你的 App。

移动端——Google Play Store：

• App 图标（512x512 PNG，32 位带 alpha 通道）
• 商店特色展示图（1024x500）
• 截图：至少 2 张，最多 8 张；每种受支持的设备形态（手机、平板）至少提供 1 张
• 简短描述（80 个字符）、完整描述（4000 个字符）
• 内容分级问卷（基于 IARC）
• 隐私政策 URL（必填）
• 数据安全部分：申报所有数据收集、存储和共享做法
• 目标 API 级别必须满足 Google 当前的最低要求。**截至 2025 年 8 月 31 日，必须达到目标 API 级别 35（Android 15）。**不符合要求的 App 将对使用较新 Android 版本的用户隐藏。请每年核查——这项要求会变化。 主机平台 — 首方认证：
• PlayStation（TRC）：技术要求清单。涵盖控制器行为、与系统软件的交互、奖杯实现、存档数据处理和网络功能。请预留 2–4 周用于 Sony QA 审核。
• Xbox（XR）：Xbox 要求。涵盖成就实现、丰富状态、控制器输入和无障碍功能。请预留 2–4 周用于 Microsoft 认证。
• Nintendo Switch（Lotcheck）：Nintendo 的合规性测试。涵盖按键提示与控制器布局匹配、掌机／底座模式切换和睡眠模式处理。请预留 2–4 周用于 Nintendo 审核。
• 所有主机平台的提交都应先依据已发布的要求清单进行内部预认证审核。

**阶段 2 关卡：**所有商店素材均已准备并审核。已满足各平台的所有提交要求。商店页面已起草，并由至少两人审核（一人检查准确性，另一人检查营销效果）。

---

阶段 3：营销素材清单

这些素材应与阶段 2 同步准备，但需单独跟踪，因为它们面向不同的分发渠道。

媒体资料包：

• 信息表：游戏名称、开发者、发行商（如适用）、发布日期、平台、价格、一句话简介、100 字简介、主要特色（5–7 个要点）
• 主视觉图：至少准备游戏的主要宣传图片，并提供可用的最高分辨率版本（印刷用 300 DPI、网页用 72 DPI，两种版本都要提供）
• 截图包：精心挑选 10–15 张截图，展现游戏的多样内容（游戏玩法、探索、战斗、叙事、环境）。按主题整理，同时提供显示和隐藏 HUD 的版本。
• GIF 动图：3–5 个短循环动图（每个 5–10 秒），展示令人满足的游戏瞬间。对于视频自动播放不可靠的社交媒体和消息平台，这些动图至关重要。
• Logo 资源包：提供游戏 Logo 的全彩、白色和黑色版本。使用 SVG 或高分辨率透明 PNG。还应包含开发者／工作室 Logo。
• 团队简介：简要介绍工作室、团队规模、值得关注的过往作品，以及媒体咨询联系信息
• 所有素材都应通过单一 URL 下载（Google Drive、Dropbox，或工作室网站上的专用媒体页面）

预告片制作：

• 游戏玩法预告片（60–90 秒）：展示实际游戏玩法，而非电影级渲染画面。玩家想看到自己将体验的内容。开头应呈现最具视觉冲击力或机制最独特的时刻。结尾应给出明确的行动号召（发布日期、平台、愿望单／预购链接）。
• 发售预告片（30–60 秒）：时长更短、情感冲击力更强，专为社交媒体设计。可结合游戏玩法和电影化片段。针对无音频自动播放进行优化（用文字叠加呈现关键信息）。
• 平台专属预告片：部分平台（Steam、App Store、Nintendo eShop）对预告片格式、分辨率和内容限制有特定要求。上传前请确认。

社交媒体发布素材：

• 为各个平台（Twitter/X、Instagram、TikTok、Reddit、Discord、YouTube 社区）起草发售公告
• 标签策略：主要游戏标签、类型标签、活动标签（如在节日期间发售）
• 社区通知计划：Discord 公告、邮件列表、Steam 更新帖
• 发售日发布安排：协调各个平台的发布时间，以最大限度地扩大覆盖范围 媒体联络：
• 媒体名单：至少列出 50 家相关媒体、YouTuber、主播和记者。优先选择报道你所在游戏类型的对象。
• 评测码分发：为媒体准备 Steam 密钥、主机平台代码或直接提供游戏构建版本。使用密钥管理服务（Keymailer、Woovit 或手动维护电子表格）。
• 评测禁发管理：设定明确的评测禁发日期，并明确告知对方。通常会在发售前 1–3 天解除禁发，以便评测发布并带动愿望单。
• 媒体联络邮件：个性化撰写（不要群发），内容简洁，包含媒体资料包链接、密钥/代码和评测禁发日期。提前 2–3 周发送。

**阶段 3 门槛：**媒体资料包已完成并发布。所有预告片均已制作并上传。社交媒体帖子已起草并安排发布。已开始联系媒体并告知评测禁发日期。

---

阶段 4：合规与法律

本阶段事项不可妥协。跳过或推迟合规任务会造成法律责任，并带来产品从商店下架的风险。

年龄分级：

• ESRB（北美）：通过 ESRB 在线工具提交内容问卷。纯数字版发售的处理时间通常为 1–3 个工作日。在美国销售的主要商店都要求提供此分级。
• PEGI（欧洲）：通过 IARC（国际年龄分级联盟）门户提交。大多数数字商店使用 IARC 自动评定 PEGI 分级。
• CERO（日本）：在日本发售必须取得此分级。处理时间较长（2–4 周）。请提前提交。
• USK（德国）：数字版通过 IARC 办理。
• 保留游戏销售地区的所有分级证书。

无障碍声明：

• 记录游戏支持的无障碍功能：可重新映射的控制方式、色盲模式、字幕选项、屏幕阅读器支持、难度选项、操作便利性设置。
• 参照 WCAG 2.1 AA 准则和 Game Accessibility Guidelines（gameaccessibilityguidelines.com）。
• 如实说明不支持的功能。内容不完整但诚实的无障碍声明，远胜于虚构的全面声明。

隐私政策：

• 任何会收集任何数据的游戏都必须提供隐私政策（包括分析数据、崩溃报告、云存档或账户创建相关数据）。
• 必须说明：收集哪些数据、如何使用、与谁共享、保留多久，以及玩家如何请求删除数据（GDPR 赋予的删除权）。
• 必须能在游戏内访问（通常从设置或主菜单链接）。
• 如果游戏面向 13 岁以下玩家（ESRB E 或 E10+），必须遵守 COPPA（收集数据须取得家长同意）。

EULA / 服务条款：

• 支持在线功能的游戏必须提供。建议所有商业发售的游戏都提供。
• 应涵盖：许可授权、限制、责任限制、争议解决、终止条件。
• 如果游戏包含用户生成内容，EULA 必须说明内容所有权和审核权。

版权与许可核查：

• 审查所有第三方素材：音乐、音效、字体、中间件、纹理、模型。
• 核实每项素材的许可条款：是否允许商业用途？是否要求署名？是否存在收入门槛？
• 检查所有中间件许可：物理引擎、网络库、UI 框架、分析 SDK。部分许可按作品或收入收费。
• 开源许可合规：如果游戏使用任何开源代码，请核实许可义务。MIT 和 BSD 许可较为宽松。GPL 要求公开源代码。Apache 2.0 要求提供 NOTICE 文件。
• 创建演职员名单画面或文本文件，列出所有要求的署名信息。

**阶段 4 门槛：**已取得所有年龄分级。隐私政策已发布，且可在游戏内访问。EULA 已由具备法律知识的人士审核（最好是律师）。已核实所有第三方素材符合许可要求。演职员名单已完成。

---

📊 市场背景 了解竞争格局对于设定切合实际的上线预期和调整营销投入至关重要。这些数字令人警醒，但不可忽视：

• 仅 2025 年，就有 20,017 款游戏在 Steam 上发行。你的游戏每天都要争夺关注度，每天约有 55 款新游戏发布。
• 其中 83% 的游戏首年收入不足 10,000 美元。长尾效应极其显著。
• **40% 的游戏未能收回 100 美元的 Steam Direct 上架费。**近半数发行作品实际上都没有进入市场视野。
• **想在上线当天获得有意义的算法曝光，至少需要 7,000–10,000 个愿望单。**Steam 的算法会奖励发展势头——在头 48 小时内迅速售出的游戏，会被推荐到更多商店页面和推荐信息流中。低于这一愿望单门槛，算法基本上会忽略你的游戏。
• **排名前 1% 的独立游戏获得了独立游戏总收入的 90%。**这是赢家通吃大部分，而非赢家通吃全部的格局，但收入集中程度极高。
• **独立游戏的财务失败率为 70%。**十款商业独立游戏中，有七款的收入不足以资助下一个项目。这并不是放弃的理由，而是认真规划营销、将其视为与开发同等重要工作的理由。

这些数字并非为了打击信心，而是为了确保你的上线计划包含充足的营销投入、切合实际的收入预测，并清楚了解对你的项目而言，“成功”意味着什么。一款售出 500 份并为后续 Game Jam 项目提供资金的游戏，按一种标准来看就是成功。一款售出 5,000 份、但需要售出 50,000 份才能实现盈亏平衡的游戏，按另一种标准来看就是失败。在上线前，先明确你的成功门槛。

---

⚖️ 法规合规检查点

除了年龄分级和隐私政策，游戏相关的监管范围也在迅速扩大。请逐项评估以下规定是否适用于你的作品：

• EAA（《欧洲无障碍法案》）：自 2025 年 6 月起具有强制执行力。适用于在欧盟销售、带有通信功能（聊天、语音）或电子商务功能（游戏内购买）的游戏。要求为核心交互提供无障碍替代方案。不合规可能导致游戏在欧盟受到市场准入限制。
• CVAA（《21 世纪通信与视频无障碍法案》）：聊天和语音功能必须让残障玩家也能使用。适用于在美国发行且具有通信功能的游戏。每次违规罚款最高达 140 万美元。涵盖实时文本、字幕，以及通信功能的 UI 导航。
• COPPA（《儿童在线隐私保护法》）：重要——合规期限为 2026 年 4 月 22 日（迫在眉睫）。 FTC 最终版 COPPA 规则修订扩大了“个人信息”的定义，将生物识别标识符纳入其中。新增要求：必须制定正式的信息安全计划；向与服务“并非不可分割”相关的第三方披露数据时，必须单独征得家长同意。如果你的游戏有理由被认为可能吸引儿童（E 或 E10+ 分级、卡通美术风格、教育内容），就必须遵守 COPPA。请立即依据更新后的规则审查你的数据收集做法。
• PEGI 2026 年更新：自 2026 年 6 月起生效。仅适用于新提交的游戏。包含战利品箱机制的游戏最低获 PEGI 16 级分级。包含 NFT 或区块链集成的游戏将自动获 PEGI 18 级分级。此外：限时优惠（战斗通行证、季节性物品）最低获 PEGI 12 级分级。每日任务和连续登录奖励最低获 PEGI 7 级分级，并新增“参与度机制”描述符。没有屏蔽／举报系统的不受限通信功能将自动导致 PEGI 18 级分级。请在规划变现模式和社交功能时考虑这些分级影响。注意： ESRB 已明确拒绝采用 PEGI 的互动风险类别方案，并表示“如果与内容无关的功能影响分级类别的判定，可能会造成混淆”。北美地区的分级仍仅依据内容。
• ESA 无障碍游戏倡议：Xbox 商店现已上线 24 个标准化无障碍标签（主机、PC、移动端、网页）。创始成员：EA、Google、Microsoft、Nintendo of America、Ubisoft。其他成员：Amazon Games、Riot、Square Enix、Warner Bros.。准确填写这些标签有助于提升游戏在关注无障碍体验的玩家中的可发现性，并体现你对新兴无障碍标准的善意遵循。预计其他商店也将效仿 Xbox 的做法。
• Steam AI 披露（2026 年 1 月三层框架）：
  • 预生成 AI 内容：嵌入游戏文件中的 AI 资源（纹理、美术、语音台词、背景设定文本）。必须在商店页面的内容描述中标注。
  • 实时生成 AI 内容：在运行时由 AI 创建的内容（动态 NPC 对话、程序化任务）。必须设置安全防护措施，防止生成非法／冒犯性内容，并提供玩家举报机制。
  • 开发者工具：代码助手、调试工具、内部流水线 AI。**明确免于披露。**在开发工作流中使用 AI 无需在商店页面披露。
  • 请在 @templates/ai-content-policy.md 中记录你的 AI 使用层级，以确保按照各商店的要求正确披露。
• itch.io AI 披露：生成式 AI 内容必须明确标记——这也包括经过手动编辑的 AI 输出（编辑 AI 生成的美术内容并不能免除披露义务）。未标记的 AI 内容将从浏览和搜索结果中下架。带有 AI 标签的项目会显示在单独的“AI 辅助”浏览页面中，实际上会降低其可发现性。批量制作的 AI 页面会被视为垃圾内容。标签要求同时适用于游戏页面元数据和游戏描述。
• 主机认证：每个第一方平台（Sony、Microsoft、Nintendo）都要求单独通过认证，耗时 2–4 周。规划提交时间时，请预留至少一轮被拒后重新提交的周期。首次提交很少能一次通过。请在上线计划中为主机认证总共预留 4–8 周。 请在目标上线日期至少提前 8 周，与你的团队一起（如果是独立开发者，也可以自己）审查此清单。临近最后一刻才浮现的监管要求，是最常见的可避免上线延误原因。

---

阶段 5：首日补丁规划

你提交认证或商店审核的版本，几乎从来不是玩家首日实际体验的版本。从提交到上线期间，总会发现问题。请提前规划。

已知问题清单：

• 汇总金版中包含的所有已知问题，并按严重程度和对玩家的可见性分类。
• 标明哪些问题会在首日补丁中修复，哪些问题会按现状接受（并说明理由）。
• 这份清单对社区管理也很有价值——如果玩家在上线当天报告已知问题，支持团队就能立即回应：“我们已知悉此问题，修复内容已包含在首日补丁中。”

首日补丁范围：

• 在上线前确定补丁内容，不要等到上线当天才被动应对。
• 首日补丁的典型范围：认证期间发现的 Bug 修复、根据后期试玩进行的最终平衡调整、本地化修正、最后阶段的性能优化。
• 不要利用首日补丁添加功能。功能新增应放在上线后更新中，而非补丁中。
• 按与金版相同的验证流程测试首日补丁（简化版阶段 1）。引入新 Bug 的首日补丁还不如不发布补丁。

热修复流程：

• 建立紧急热修复流程：代码修复、构建、测试、部署。从“报告严重 Bug”到“修复在所有平台上线”，最短需要多长时间？
• 对于 PC（Steam）：热修复通常可在数小时内部署。记录推送 Steam 版本更新的流程。
• 对于主机：热修复必须经过认证（如果问题严重，则采用简化的快速通道流程）。了解每个平台的加急认证流程和联系人。
• 对于移动平台：App Store 审核可能需要 24-48 小时。Google Play 通常更快（数小时）。请将这些时长纳入响应时间预估。
• 指定有权批准紧急热修复部署的人选。这不应需要召开全员会议——上线周应由一位决策者负责，并确保其全天候可联系。

监控基础设施：

• 崩溃报告：集成崩溃报告服务（Sentry、Backtrace、Crashlytics 或引擎原生服务）。确认其在发布版本中处于启用状态。
• 分析：针对玩家进度、会话时长和流失节点收集基本遥测数据。这些数据对于上线后的平衡调整和内容规划极具价值。
• 社区舆情跟踪：监控 Steam 评价、社交媒体提及、Discord 活动和 Reddit 帖子。指定社区经理或团队成员在上线周负责此项工作。
• 服务端监控（如适用）：设置仪表板，监控玩家人数、服务器负载、错误率和延迟。配置异常行为的告警阈值。

**阶段 5 关卡：**已完成已知问题清单。首日补丁范围已确定并完成测试。热修复流程已完成端到端测试（向暂存环境部署测试补丁）。监控基础设施已启用并验证。

---

阶段 6：是否上线决策

这是最后一道关卡。上线决策应由团队共同作出，并全面了解此前每个阶段的状态。

清单审查：

• 每个阶段的负责人汇报完成情况：完全完成、有例外但已完成（列出例外），或未完成（列出阻碍因素）。
• 审查所有例外，并明确接受或升级处理。
• 任何未完成的阶段都可能阻碍上线。团队必须就带着未完成事项上线的风险是否可以接受达成一致。

风险评估： 评估以下风险类别：

风险类别	问题	风险发生后的影响
技术	游戏是否可能在常见硬件配置上崩溃？	口碑尽毁。退款激增。
性能	最低配置下的帧率是否可能低于可接受水平？	首次印象不佳。Steam 评论遭到刷差评。
内容	是否存在冒犯性、误导性或缺失的内容？	公关危机。商店页面被下架。
法律	是否存在尚未解决的许可或合规问题？	DMCA 下架通知。法律责任。
服务端（如适用）	发售首日的流量是否可能压垮基础设施？	玩家无法游玩。收到退款申请。
营销	游戏在商店页面上是否容易被发现？	尽管游戏品质出色，销量仍然低迷。

为每项风险评定可能性（低／中／高）和影响（低／中／高）。任何高可能性、高影响的风险都应阻止发售，除非团队负责人明确接受该风险。

回滚计划： 明确发售出现灾难性问题时的应对措施：

• 能否暂时下架商店页面？流程是什么？
• 能否回退出现问题的版本，恢复到上一版本？需要多长时间？
• 谁负责与玩家沟通？沟通内容是什么？起草一份「我们已知悉问题，正在修复」的公告模板。
• 何时应将发售判定为「取消」，而非「状况不佳但继续推进」？明确判断标准。

发售日作战室：

• 指定发售日及之后 48 小时内的值班人员。若团队分布在不同时区，应覆盖所有时区。
• 建立沟通渠道：主要渠道（Slack／Discord 频道）、升级渠道（电话）和公开渠道（社交媒体、社区论坛）。
• 明确升级路径：由谁决定部署热修复？由谁决定撤回版本？
• 安排检查时间点：发售后 +1 小时、+4 小时、+12 小时、+24 小时、+48 小时。每次检查都要查看崩溃报告、玩家反馈、销售数据和服务端健康状况。

决策：

• GO：所有阶段均已完成（或已完成，但存在明确接受的例外）。不存在高可能性、高影响的风险。回滚计划已就绪。作战室人员已到位。
• 有条件 GO：继续发售，但须满足特定条件。例如：「GO，前提是首日补丁在发售日早上 6 点前成功部署。」明确未满足条件时的应对措施。
• NO-GO：仍有一个或多个发售阻碍问题尚未解决。确定新的目标日期和解决方案。坦诚说明延期情况——相比仓促发售且问题重重的游戏，延期后顺利发售的游戏会给玩家留下更好的印象。

---

阶段 7：发售后运营

发售日是开始，而不是结束。发售后的前 30 天，将决定你的游戏是积累势头，还是逐渐沉寂在 Steam 的坟场中。本阶段介绍维持在线游戏运营所需的工作节奏。

补丁发布节奏规划

设定三个不同的更新层级，并为每个层级安排不同的发布周期：

PATCH CADENCE MODEL
-------------------------------------------------
HOTFIXES (days 1-7 post-launch, then as needed):
  Scope: Crash fixes, progression blockers, data loss bugs, critical
  balance breaks (one weapon doing 10x intended damage)
  Turnaround: 24-72 hours from report to live
  Process: Fix → abbreviated QA → deploy → verify
  Communication: "We are aware. Fix incoming." posted within 2 hours
  of confirmed report. Players tolerate bugs. They do not tolerate silence.

CONTENT PATCHES (every 2-4 weeks for first 3 months):
  Scope: Balance tuning based on live data, quality-of-life improvements,
  bug fixes batched from the tracker, minor content additions (new items,
  cosmetics, challenges)
  Turnaround: 1-2 sprint cycles
  Process: Plan → build → QA → staging → deploy → monitor
  Communication: Patch notes published 24 hours before deployment.
  Write patch notes for players, not developers. "Sword damage reduced
  15%" means nothing. "The Iron Sword was trivializing mid-game bosses,
  so we brought its damage closer to other tier-2 weapons" tells a story.

  Dead Cells' patch cadence: biweekly during Early Access, monthly after
  1.0, with each update clearly themed (the "Rise of the Giant" DLC,
  the "Bad Seed" expansion). Every patch had a narrative identity.

MAJOR UPDATES (every 3-6 months):
  Scope: New content (areas, enemies, bosses, mechanics), system overhauls,
  seasonal events, paid DLC
  Turnaround: Full milestone planning cycle
  Process: Design → prototype → build → extended QA → marketing push → deploy
  Communication: Announce 2-4 weeks in advance with trailer or dev blog.
  Time major updates with Steam sales for maximum visibility.

  Stardew Valley model: free major updates as community-building investment.
  ConcernedApe shipped 1.1, 1.2, 1.3, 1.4, and 1.5 as free updates over
  5 years, each one reigniting press coverage and sales. The free updates
  generated more revenue through base game sales than paid DLC would have.
-------------------------------------------------

社区管理策略

社区是你最强大的营销渠道，也是最危险的风险来源。要有计划地管理社区。

COMMUNITY CHANNELS (priority order for most indie games)
-------------------------------------------------
Discord:
  Set up BEFORE launch. Have channels for: announcements, bug reports,
  feedback, general discussion, fan art/content. Assign moderators.
  Respond to bug reports within 4 hours during launch week.
  Run a "known issues" pinned post updated in real-time on launch day.

Steam Forums:
  Monitor daily for the first month. Steam forum sentiment directly
  influences store page visibility. Respond to negative posts with
  empathy and specifics -- "We hear you. This is on our radar for
  the next patch" turns a detractor into a watcher.

Reddit:
  Post launch announcement in relevant subreddits (r/indiegaming,
  genre-specific subs). Be present in comments. Do NOT astroturf.
  Reddit detects and punishes corporate-feeling engagement instantly.

Twitter/Social:
  Share GIFs of satisfying moments, patch previews, player
  achievements. The Vampire Survivors social strategy was almost
  entirely player-generated content retweets -- free, authentic,
  and more effective than any marketing campaign.
-------------------------------------------------

指标监控仪表板

发售后的前 30 天每天跟踪以下指标，此后每周跟踪：

POST-LAUNCH METRICS
-------------------------------------------------
Retention:
  D1 retention (% who play again within 24 hours): Target 40%+
  D7 retention: Target 20%+
  D30 retention: Target 10%+
  If D1 < 30%, the first-time experience has a critical problem.
  If D7 drops sharply from D1, mid-game content is failing.

Engagement:
  Median session length: Compare to your design target
  Sessions per week per active player
  Completion rate: % who reach credits (for narrative games)
  Compare to Hades benchmarks: ~20 hours median to first clear

Revenue (if commercial):
  Daily revenue and 7-day moving average
  Revenue per user (RPU) by acquisition source
  Refund rate: above 10% is a red flag, above 20% is a crisis
  Wishlist conversion rate on launch day: industry average ~15-20%

Sentiment:
  Steam review score: track daily. Below 70% "Mixed" threshold
  triggers a community response plan.
  Review keyword frequency: what are players praising/complaining about?
  Net Promoter Score from in-game surveys (if implemented)

Stability:
  Crash rate: target < 0.5% of sessions
  Average FPS across hardware tiers
  Error log volume (trending up = new bugs introduced by patches)
-------------------------------------------------

发售后内容路线图模板

请在发售前起草这份路线图。它能让团队保持专注，也能让社区有所期待。

POST-LAUNCH ROADMAP
-------------------------------------------------
Month 1: Stability & Balance
  - Hotfixes for launch issues
  - Balance pass based on live data (not dev intuition)
  - Quality-of-life improvements from community feedback
  - "Thank you" patch with 1-2 small community-requested features

Month 2-3: First Content Update
  - [Themed content addition: new area/mode/characters]
  - Major balance overhaul if needed
  - Accessibility improvements from player feedback

Month 4-6: Major Content Drop
  - [Significant expansion: new mechanics, story content, or game mode]
  - Align with a Steam sale or seasonal event for visibility
  - Press outreach for "now with [new feature]" coverage

Month 6-12: Sustained Operations or Sunset
  Decision point: Is the game growing, stable, or declining?
  - Growing: Plan next content year, consider DLC or expansion
  - Stable: Maintain with quarterly patches, shift team to next project
  - Declining: Ship a final "definitive edition" patch, communicate
    honestly with community, redirect resources

The Hades model: 10 major content updates during Early Access,
each one adding weapons, characters, story content, and systems.
Each update had a themed identity and generated fresh press coverage.
By 1.0, the game had 18 months of community investment behind it.
-------------------------------------------------

---

输出格式

## Launch Readiness Report: [Game Title]
## Target Launch Date: [YYYY-MM-DD]
## Report Date: [YYYY-MM-DD]
## Report Author: [Name/Role]

### Executive Summary
[3 sentences: Overall readiness state, biggest remaining risk, recommendation (GO/CONDITIONAL GO/NO-GO)]

### Phase Completion Status

| Phase | Status | Exceptions | Owner |
|-------|--------|-----------|-------|
| 1. Build Validation | Complete / With Exceptions / Incomplete | [list] | [name] |
| 2. Storefront Requirements | Complete / With Exceptions / Incomplete | [list] | [name] |
| 3. Marketing Assets | Complete / With Exceptions / Incomplete | [list] | [name] |
| 4. Compliance & Legal | Complete / With Exceptions / Incomplete | [list] | [name] |
| 5. Day-One Patch | Complete / With Exceptions / Incomplete | [list] | [name] |

### Blocking Issues
| ID | Issue | Phase | Severity | Resolution Path | ETA |
|----|-------|-------|----------|----------------|-----|
| L1 | [desc] | [phase] | Blocker | [plan] | [date] |

### Risk Assessment

| Risk | Likelihood | Impact | Mitigation | Accepted? |
|------|-----------|--------|-----------|-----------|
| [risk] | H/M/L | H/M/L | [plan] | Y/N |

### Rollback Plan
- Build reversion process: [description]
- Storefront takedown process: [description]
- Public communication template: [drafted message]
- Abort threshold: [criteria]

### War Room Configuration
- On-call team: [names and roles]
- Communication channels: [primary, escalation, public]
- Check-in schedule: [times]
- Escalation path: [who decides what]

### Post-Launch Operations Plan
- Patch cadence: [hotfix/content/major schedule]
- Community channels: [platform list with owners]
- Metrics dashboard: [tool and key metric targets]
- Content roadmap: [month-by-month plan]

### Decision: [GO / CONDITIONAL GO / NO-GO]
**Conditions (if CONDITIONAL GO):** [list]
**Reasoning:** [2-3 sentences]
**Next Steps:** [immediate action items]

质量标准

• 阶段完整性：每个阶段都已评估，即使结论是“与本项目无关”（并说明理由）也不例外。
• 不含含糊其辞的表述：必须明确记录每个例外和每项已接受的风险，并说明理由。“到时候再说”不是有效的发布就绪报告条目。
• 回滚计划经过测试：回滚计划不是纸上谈兵，而是在预发布环境中经过测试。尚未执行过的回滚计划只是愿望，不是计划。
• 战情室人员到位：每项关键职能（工程、社区管理、平台关系）都安排了具名的值班人员，并已确认其可随时响应。
• 法律核验完成：所有第三方素材均已核验。所有合规要求均已满足。此方面不存在任何模糊之处。
• 已有发布后计划：已明确补丁发布频率、建立社区渠道、配置指标仪表板并起草内容路线图。没有发布后计划的游戏，生命周期只有一周。
• 决策可追溯：可以根据具体的完成状态和风险评估追溯上线或不上线的决策。未来的事后复盘应能准确还原决策时已知的信息。

MCP 集成

发布工作流连接了用于发布管理、营销素材制作、媒体联络和部署的 MCP 服务，从而能够在单个会话中协调整个发布流程。

已连接的 MCP 服务

MCP 服务	发布用途	帮助方式
GitHub（已连接）	发布管理	创建包含变更日志的发布标签和 GitHub Releases，管理首日补丁分支，使用里程碑标签跟踪阻塞发布的问题，并通过 PR 工作流协调紧急修复流程
Gmail（已连接）	媒体联络	起草并发送个性化媒体联络邮件，附上媒体资料包链接、评测禁发日期和评测码。管理与记者和主播的后续邮件往来。
Canva（已连接）	营销素材	生成商店页面图片、社交媒体发布公告、媒体资料包的主视觉变体以及发布日倒计时素材
Vercel（已连接）	Web 部署	部署游戏营销网站、媒体资料包页面或 Web 游戏版本。适用于配套应用、社区门户和 Web 演示版部署。
Cloudflare（已连接）	CDN 和存储	为可下载版本和媒体资料包配置 R2 存储，为排行榜或社区功能设置 D1 数据库，并管理通过 Web 提供的游戏素材的 CDN 缓存
Slack（已连接）	战情室协调	在团队频道发布发布状态更新，协调战情室签到安排，分发崩溃报告警报和舆情监测摘要
Notion（已连接）	发布清单跟踪	将发布就绪报告作为结构化 Notion 页面维护，记录各阶段完成状态、阻塞问题和团队可查询的风险评估

示例工作流

发布标签和更新日志：

1. 使用 GitHub MCP 从黄金构建提交创建发布标签
2. 根据上次发布以来已合并的 PR 描述生成更新日志
3. 创建 GitHub Release，附上更新日志，并链接到已知问题和首日补丁范围
4. 首日补丁部署后，使用补丁内容更新发布说明

媒体资料包分发：

1. 使用 Canva 生成商店页面胶囊图和社交媒体公告图片
2. 通过 Gmail MCP 起草个性化媒体联络邮件，附上媒体资料包下载链接和新闻禁发日期
3. 将媒体资料包页面部署到 Vercel，提供简洁且符合品牌形象的下载体验
4. 通过 Gmail 邮件串跟踪回复，并跟进感兴趣的媒体

发布日作战室：

1. 在发布后第 0 小时将发布状态模板发布到 Slack
2. 监控 GitHub 中带有 P0/P1 标签的新 bug 报告
3. 在每个检查间隔（+1h、+4h、+12h、+24h、+48h）汇总崩溃报告摘要和用户情绪数据
4. 将最新状态发布到 Slack 和 Notion，并附上当前风险评估
5. 如果需要紧急修复，通过 GitHub MCP 管理 PR 和部署

示例用例

1. “我们的独立游戏已完成全部功能，计划在 6 周后于 Steam 上发布。请带我走完整个发布流程，并帮我制定时间表。”
2. “我们要首次提交 App Store。需要满足哪些具体要求？有哪些常见的拒绝原因需要避免？”
3. “我们的游戏下周五发布，但刚发现了一个重大 bug。请帮我评估这是发布阻断问题，还是可以放到首日补丁中处理。”
4. “我们需要为即将发布的版本准备媒体资料包。里面应该包含哪些内容，又该如何组织？”
5. “我们正在讨论是将发布推迟两周以修复剩余 bug，还是按时发布并推出首日补丁。请帮我将其整理为包含适当风险评估的是否发布决策。”
6. “我们上周刚发布，评价褒贬不一。请帮我制定发布后的运营计划，包括补丁节奏、社区回应策略和内容路线图，以扭转评价。”