角色扮演
🏦 场景与客户
一家以剧情见长的工作室，在做一款角色扮演游戏，目标平台 PC 与主机。团队三十人左右，其中策划与文案占三分之一，程序 7 人。
项目最大的负担不是战斗，是内容量。主线加支线有大量对话与分支，早期用脚本硬写，每个任务一段代码。改一句台词要程序改脚本、重新打包；不同语言版本的文本混在脚本里，本地化团队拿不到干净的表。上线前发现有几条支线的状态标记互相覆盖，玩家做完 A 任务后 B 任务无法触发。
📅 实施节奏
- 第 1–3 周：把剧情文本从脚本里全部剥出，形成结构化文本表，明确每条的说话人、条件与后续
- 第 4–7 周：搭建任务状态机，用状态与条件声明任务流程，不再用代码写分支
- 第 8–11 周：接入本地化流程，文本表按语言导出，译文回填后自动校验占位符与长度
- 第 12 周起：加入剧情走查工具，可一键跑完整条任务链，检查是否存在不可达与死锁
🗝️ 方案要点
- 数据驱动的剧情：对白、分支、条件全部是数据，策划自己改自己验，不再排队等程序
- 状态互斥检查：任务状态集中管理，同名或互斥标记在保存时就报错，而不是等到玩家卡住才发现
- 文本与代码分离：代码里只出现键，不出现正文，本地化与校对都能独立进行
- 养成曲线与剧情解耦：数值成长走独立配置，剧情按章节给固定资源，避免剧情推进把平衡打乱
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 剧情实现 | 数据驱动状态机 | 策划自主、可校验；代价是表达能力有上限，遇到极特殊的演出仍要写一段专用逻辑 |
| 任务系统 | 通用框架 + 少量定制 | 复用度高、工具齐全；代价是通用框架为了兼容各种任务会变复杂，新人上手门槛上升 |
| 本地化 | 文本表导出回填 | 流程干净、可自动化校验；代价是文本从定稿到进游戏多了一道流水线，急改台词会变慢 |
| 养成曲线 | 与剧情解耦 | 平衡稳定；代价是玩家推进剧情时的成长感被削弱，需要靠装备与技能补回反馈 |
🚧 实施难点与排查
- 任务状态互相覆盖：两个支线共用了同一个标记位。改为状态命名空间隔离，并在保存时做冲突检测
- 译文占位符错位：译文替换时丢了变量占位。加入自动校验，占位符数量不一致直接卡住流程
- 某条支线永远触发不了：前置条件依赖一个已被主线清除的标记。用剧情走查工具跑出来后定位到条件写反
- 文本改完没生效：早期打包时文本走缓存。改为按内容哈希判断是否需要重新导入
💵 成本与收益
- 成本：工具链建设约 3 人 × 9 周；收益主要在人力，不在算力
- 收益：策划改台词的周期从「一天」变成「几分钟」；本地化交付返工明显减少
- 省钱的点：剧情类问题一旦流出到玩家手里，修起来要走补丁流程，代价远高于在工具里拦下来
🛡️ 风险与保障
- 内容安全：文本入库前做敏感词与合规检查，避免上线后被动下架
- 版本一致：文本、状态机、本地化包三者版本绑定，不出现错配
- 可回滚：剧情配置带版本，出问题退回上一版
- 进度保护：状态机改动要兼容老存档中已完成的进度，不允许让玩家重做
♾️ 可复用与演进
- 「文本表 + 状态机 + 本地化流水线 + 走查工具」可平移到任何重叙事的品类
- 演进方向：把分支热度回流给文案，找出玩家跳过的段落并优化
- 再进一步：接入语音与配音流水线，让文本改动自动带出待录清单
