348 lines
12 KiB
Markdown
348 lines
12 KiB
Markdown
# 67 · 上线后策略（Post-Launch Strategy）
|
||
|
||
> **所属文档集** [← 返回索引](./README.md) · [总览](./00_Overview.md)
|
||
> **关联文档** 00_Overview · 01_ProjectSchedule
|
||
> **文档性质** 产品运营策略文档。涵盖热更新策略、DLC 规划、社区运营和数据分析方向。
|
||
|
||
---
|
||
|
||
## 目录
|
||
|
||
1. [发布后阶段划分](#1-发布后阶段划分)
|
||
2. [热更新策略（Hot-Patch Policy）](#2-热更新策略hot-patch-policy)
|
||
3. [版本更新计划](#3-版本更新计划)
|
||
4. [DLC 规划](#4-dlc-规划)
|
||
5. [社区运营策略](#5-社区运营策略)
|
||
6. [数据分析与玩家行为监测](#6-数据分析与玩家行为监测)
|
||
7. [用户反馈处理流程](#7-用户反馈处理流程)
|
||
8. [长期生命周期规划](#8-长期生命周期规划)
|
||
|
||
---
|
||
|
||
## 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 游戏数据（存档）的向后兼容性
|
||
|
||
**核心规则**：每次版本更新，旧版本存档必须能在新版本中正常加载。
|
||
|
||
执行方式：
|
||
```csharp
|
||
// 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 众筹模式，按需生产 |
|