12 KiB
12 KiB
67 · 上线后策略（Post-Launch Strategy）
所属文档集 ← 返回索引 · 总览
关联文档 00_Overview · 01_ProjectSchedule
文档性质 产品运营策略文档。涵盖热更新策略、DLC 规划、社区运营和数据分析方向。
目录
1. 发布后阶段划分
Phase 0：发布准备期（上线前 2 周 ~ 上线当天）
- 存档系统最终测试
- 平台认证（Nintendo / Steam / PlayStation）
- 压力测试（Steam Workshop 服务器）
- 营销材料最终确认（Trailer / Screenshots）
Phase 1：稳定期（上线后 0 ~ 4 周）
- 重心：修复游戏破坏性 Bug，不发布新内容
- 目标：游戏崩溃率 < 0.1%，平均 metacritic 无明显评分拖累性 Bug
Phase 2：打磨期（上线后 1 ~ 3 个月）
- 根据玩家数据调整平衡性
- 发布 v1.1 / v1.2 补丁
- QoL（生活质量）改进
Phase 3：扩展期（上线后 3 ~ 12 个月）
- DLC 开发与发布（如果销售满足目标）
- 主要社区活动
Phase 4：维护期（12 个月后）
- 仅针对平台兼容性问题更新
- 停止新内容开发
2. 热更新策略（Hot-Patch Policy）
2.1 热更新触发条件
| 优先级 | 问题类型 | 响应时间 | 处理方式 |
|---|---|---|---|
| P0 紧急 | 存档损坏/数据丢失 | 24h 内 | 立即热修复 + 官方公告 + 数据恢复方案 |
| P0 紧急 | 游戏无法启动（影响 >1% 用户） | 24h 内 | 立即热修复 |
| P1 高 | 游戏进度永久卡死（流程断裂） | 72h 内 | 热修复 |
| P1 高 | 严重平衡性问题（某技能/机制使游戏变得无趣） | 1 周内 | 补丁更新 |
| P2 中 | 视觉错误/音频错误（不影响进度） | 下次补丁 | 计划性更新 |
| P3 低 | 翻译错误/UI 显示错误 | 下次补丁 | 计划性更新 |
2.2 热更新流程
发现问题
↓
问题分类（P0/P1/P2/P3）
↓
P0/P1 → 立即通知所有相关成员 → 修复分支 → 内部 QA（最小化测试）→ 提交平台审核
P2/P3 → 进入下一个补丁版本的 Bug Backlog
↓
平台审核（Steam ~24h / Nintendo ~5-7 天）
↓
推送更新 + 更新日志
↓
监测更新后 48h 的崩溃率和用户反馈
2.3 游戏数据（存档）的向后兼容性
核心规则：每次版本更新，旧版本存档必须能在新版本中正常加载。
执行方式：
// SaveData 版本迁移系统
public class SaveDataMigrator
{
public SaveData Migrate(SaveData old, int fromVersion, int toVersion)
{
// 对每个版本增量执行迁移
for (int v = fromVersion; v < toVersion; v++)
old = _migrations[v].Apply(old);
return old;
}
}
// 示例：v1.0 -> v1.1 迁移（新增了可选探索区域 UnlockFlag）
public class MigrationV1_0_to_V1_1 : ISaveMigration
{
public SaveData Apply(SaveData d)
{
d.explorationFlags.TryAdd("SecretArea_CaveNorth", false);
return d;
}
}
禁止：任何导致旧存档不兼容（强制重新开始游戏）的更新，除非存在严重安全漏洞。
3. 版本更新计划
3.1 v1.1 补丁（预计上线后 2-4 周）
触发条件：玩家 Metacritic 用户评分稳定、无 P0 紧急问题积压
内容范围：
| 类别 | 具体内容 |
|---|---|
| 平衡调整 | 根据上线首周数据调整 Boss 伤害/血量（目标：各 Boss 普通难度平均死亡次数 5-10 次） |
| QoL 改进 | 改进地图 UI（玩家反馈最多的 UI 问题） |
| Bug 修复 | 所有 P1/P2 问题 |
| 性能 | 根据崩溃报告优化内存热点区域 |
| 本地化修正 | 已知翻译错误批量修正 |
3.2 v1.2 补丁（预计上线后 6-8 周）
内容范围：
| 类别 | 具体内容 |
|---|---|
| 内容补充 | 补充 2-3 个可选隐藏房间（玩家遗漏率 >80% 的区域） |
| 新功能 | 新增挑战模式计时器（高玩需求） |
| 无障碍 | 根据玩家反馈补充无障碍选项（如玩家报告缺少的功能） |
| 成就修正 | 修正成就触发条件不一致问题 |
3.3 v1.5 主要更新（预计上线后 3-4 个月）
触发条件：销售额 ≥ 预期目标的 60%
内容范围：
| 类别 | 具体内容 |
|---|---|
| 新游戏+ | New Game+ 模式（敌人强化，保留道具，解锁新 Lore 石板） |
| 速通模式 | 官方计时器 + 速通分类模式（任意结局/真结局/隐藏结局） |
| 观察者模式 | 无战斗观察者模式（用于欣赏 Lore 和美术） |
| 语言支持 | 新增 1-2 种语言（根据 Steam 用户地区分布决定） |
4. DLC 规划
4.1 DLC 触发门槛
| 销售目标 | DLC 计划 |
|---|---|
| 达到 A 目标（强劲） | 开发完整故事 DLC（见 §4.2） |
| 达到 B 目标（良好） | 开发小型免费 DLC（见 §4.3） |
| 未达到 B 目标 | 无 DLC；专注维护和 v1.5 |
4.2 故事 DLC："灵历前传"（The Before-Era Chronicles）
前提：正篇销售达到 A 目标（强劲）
概念：DLC 以第一纪（文明繁荣时代）为背景，玩家扮演奥拉（吞噬者的前身）。
时间线：灵历 LR 3,150 - LR 3,200（熄灭前 50 年）
核心主题：
奥拉此时还不是反派——她是一名才华横溢的研究者，在她摚友的死亡之后，
开始走上那条导致世界终结的研究道路。
玩法差异（vs 主游戏）：
- 使用奥拉的原始能力集（虚空碎片操控，非三魂系统）
- 不同的地图（繁荣时代的 5 个城邦）
- 两个结局：历史结局（无法改变，与正篇一致）/ 隐藏结局（奥拉的"另一种选择"）
规模预估：约主游戏 40% 的游戏时长（6-8 小时）
价格定位：主游戏价格的 40-50%
4.3 小型免费 DLC："失落的吟游者"（The Lost Bard）
前提：正篇销售达到 B 目标（良好）或以上
概念：新增一名 NPC（吟游者·克莱），游荡于 5 个区域，演唱隐藏曲目，并揭示一些正篇中未展示的历史角落。
内容范围：
- 新增 NPC：吟游者·克莱（新 Sprite + 对话）
- 5 首新 BGM（世界各区域的"民谣"版本）
- 10 条新 Lore 石板（主要揭示普通灵人的日常生活）
- 1 个新的可选隐藏房间（翠冠议会的档案室）
规模预估：约 1-2 小时的探索内容
价格：免费
5. 社区运营策略
5.1 发布前社区建设
| 时间 | 活动 |
|---|---|
| 发布前 3 个月 | 开放 Steam 商店页面 + 愿望单活动 |
| 发布前 1 个月 | 发布最终 Trailer（含隐藏结局彩蛋） |
| 发布前 2 周 | 邀请 20-30 名 Youtuber/Streamer 内测 |
| 发布当天 | 开发者直播游戏（展示正常通关流程） |
5.2 发布后社区维护
| 频率 | 内容类型 |
|---|---|
| 每周 | 在 Steam 社区发布"开发日志"（更新进度/修复预告） |
| 每月 | 在社交媒体发布 1 张美术分享（背景美术/角色草图） |
| 里程碑（销量节点） | 发布开发者感谢信 + 特别优惠折扣 |
| 节假日 | 游戏内限时视觉彩蛋（如节日装饰庇护所） |
5.3 玩家创作支持（UGC 友好政策）
明确允许：
- 游戏 Let's Play / 攻略视频（全程）
- 同人创作（角色 / 世界设定衍生作品）
- 游戏 OST 翻奏 / 混编（需注明出处）
- 游戏截图/美术二创
明确禁止：
- 出售未授权的实体周边
- 游戏内资产的商业使用（未经授权）
5.4 Bug 社区汇报机制
在 Steam 讨论区设立置顶的 "Bug Report 固定帖"，格式要求：
标题格式：[版本号] [严重性（P0/P1/P2）] 简短描述
正文要求：
- 操作系统 + 硬件配置
- 复现步骤（越详细越好）
- 预期行为 vs 实际行为
- 截图/录屏（可选但有帮助）
6. 数据分析与玩家行为监测
6.1 数据收集原则
- 匿名化：所有数据收集均匿名，不关联个人身份信息
- 可选退出：玩家可在设置中关闭数据收集（遵守 GDPR / CCPA）
- 透明公示：在游戏启动时的隐私政策中列明收集内容
6.2 关键监测指标（KPI）
| 指标 | 目标值（参考） | 用途 |
|---|---|---|
| 首 Boss 通关率 | > 80%（正常难度） | 教学系统有效性验证 |
| 各 Boss 平均死亡次数 | 5-10 次（正常难度） | 平衡性参考 |
| 游戏完成率（任意结局） | > 40% | 整体完成度 |
| 真结局发现率 | > 20% | 叙事引导有效性 |
| 隐藏结局发现率 | 5-10%（故意设计为较低） | 深层探索玩家奖励 |
| 平均游戏时长 | 12-18 小时（首次通关） | 内容量验证 |
| 每日活跃率（上线首月） | — | 留存参考 |
6.3 卡点分析（Funnel Analysis）
重点分析以下阶段的玩家流失：
游戏安装 → 首次游玩 → 通过第一个教学区域 → 击败首个 Boss
→ 解锁地魂 → 击败第二 Boss → 完成前三个区域 → 进入深渊
→ 击败最终 Boss → 结局
每个节点的流失率如果高于基准值，触发相应的分析和调整：
| 节点 | 流失基准（警报阈值） | 可能原因 |
|---|---|---|
| 通过教学区域 | > 30% 流失 | 教学过难/过无聊 |
| 首个 Boss | > 50% 流失 | Boss 难度过高 |
| 进入洞穴 | > 40% 流失 | 节奏感下降（注意深渊区域的"难度曲线低谷"） |
| 最终 Boss | > 60% 流失 | 最终 Boss 难度过高 |
7. 用户反馈处理流程
7.1 反馈分类
| 来源 | 处理方式 |
|---|---|
| Steam 评测（差评） | 每条 24h 内审阅；P0/P1 问题立即追踪；礼貌回复（无辩解） |
| Steam 讨论区 Bug | 统一进入 Bug Tracker |
| Twitter/微博 @ | 每日浏览，P0 问题立即响应；其他记录下来 |
| 邮件（联系方式公开） | 5 个工作日内回复 |
7.2 差评应对原则
| 原则 | 说明 |
|---|---|
| 不辩解 | 永远不用"你理解错了"或"你的操作有问题"来回复差评 |
| 感谢先行 | 始终先感谢玩家愿意留下反馈 |
| 问题承认 | 如果差评指出的是真实问题，明确承认并说明修复计划 |
| 不承诺无法实现的 | 不在回复中承诺无法交付的功能或时间 |
8. 长期生命周期规划
8.1 主机移植时间线（参考）
| 时间 | 计划 |
|---|---|
| 上线 6 个月后（如 Steam 销售良好） | 启动 Nintendo Switch 移植评估 |
| 上线 9 个月后 | 启动 PS5 移植评估 |
| 上线 12 个月后 | Xbox Game Pass 协议探索 |
移植优先级原则：像素风格 Metroidvania 在 Switch 平台有强基础受众，优先考虑。
8.2 游戏退役规划
当游戏进入维护期后（12 个月以上），游戏仍然：
- 保持在各平台商店上架（永久）
- 维护关键平台兼容性更新（OS 更新导致的崩溃等）
- 保留在线服务（Steam 成就系统等，依赖 Valve 平台）
开源计划（可选）：如果游戏决定结束所有商业运营（5 年后），考虑将游戏核心系统代码（非资产）以 MIT 许可证开源，回馈独立游戏开发者社区。
8.3 IP 延续评估
若正篇 + DLC 的总体市场反响良好，评估以下 IP 延续方向：
| 方向 | 条件 |
|---|---|
| 续作（正式第二代） | 正篇达到 AA 级销量目标 |
| 外传游戏（前传 DLC 扩展为独立游戏） | 前传 DLC 用户评分 > 正篇 |
| 动画短片（世界观推广） | 与内容创作者合作，低成本高传播 |
| 实体周边（桌游/画册） | Kickstarter 众筹模式，按需生产 |