写这篇复盘之前先交代一下项目背景。这是一个以 Unity 为引擎、由我担任游戏主程的悬疑推理向项目整体玩法偏剧情驱动玩家需要在场景中搜索线索、与角色对话、组合证据、解开谜题最终根据推理结果走向不同结局。技术栈以 Unity 2021 LTS 为主包含少量自研编辑器工具覆盖从原型验证到成包上线的完整流程。这篇文章不打算写成 API 手册而是把主程视角下真正花过时间、踩过坑、最终沉淀下来的东西整理出来从架构设计到具体系统实现再到性能优化和团队协作尽量给到能直接参考的结论。如果你正准备做同类叙事驱动游戏或者刚接手一个以剧情和谜题为核心玩法的 Unity 项目这篇文章应该能帮你少走不少弯路。文章里提到的很多决策单独看可能不起眼但组合起来决定了项目后期是否还能快速迭代。1. 项目开局选型与工程架构1.1 为什么选 Unity以及版本和渲染管线怎么定悬疑推理游戏不像重战斗的动作游戏那样对渲染有极致要求它更看重的是跨平台能力、成熟的 UI 系统、以及大量叙事内容的管理工具链。Unity 在这三方面都有比较成熟的积累尤其是 UGUI TextMeshPro 的组合做对话、线索面板、证据陈列这类高频 UI 交互非常顺手。项目团队里既有程序也有策划Unity 的编辑器易用性也让策划能直接参与场景摆放和对话调试不需要额外搭一套编辑器工具链。版本选型上我直接锁定了 Unity 2021.3 LTS。这个版本在稳定性、Burst/Job System 支持、以及各平台导出兼容性上都比较均衡。没有选 2022 LTS 的原因是当时项目中期正好赶上 2022 版本迭代团队不希望在这个节骨眼上承受升级风险。渲染管线用的是内置渲染管线Built-in Render Pipeline原因也很简单项目画面风格是偏写实但也偏静态的场景大量使用预烘焙光照贴图不需要 GPU Instancing 的大规模植被也不需要 Scriptable Render Pipeline 的自定义渲染特性。内置管线在这个量级的项目里反而是最稳妥的Shader 兼容性最好移动端适配问题也最少。1.2 工程目录划分与核心框架选择主程接手项目的第一件事就是重新划分工程目录。没有合理的目录结构后期几十个场景、上百个 prefab 会让人崩溃。我们的目录按照功能域划分而不是按资源类型划分Assets/Scenes 只放场景文件按章节子目录再分Assets/Scripts 分为 GamePlay、UI、Data、Editor、Tools 五个子域Assets/Art 下按角色、场景、特效、UI 图素分类且每个子类再按 prefab 与源文件分开Assets/Config 放所有 ScriptableObject 配置包括对话、谜题、物品、章节流程等框架层面没有上特别重的 MVVM 框架而是采用了一轻一重的组合轻量消息事件总线 状态机驱动的流程控制器。事件总线负责各模块之间的解耦比如“线索被发现”这个事件会同时被任务系统、音频系统和 UI 系统监听彼此之间不用直接引用。流程控制器则负责章节内的阶段流转例如“进入房间 - 获得线索 A - 解锁对话选项 B - 触发剧情 C”用一个可配置的 Step 数组驱动。这个设计在后面调整剧情节奏时帮了大忙策划改配置就能改变流程不需要动代码。1.3 几个必须在开工前想清楚的前期决策悬疑推理游戏有几个特性会深刻影响架构非线性探索、多分支剧情、以及随时可能被玩家“跳着玩”的场景顺序。如果前期不做好设计约束后面改起来是伤筋动骨的。第一个决策是“场景切换模式”。我们最终采用多场景并存的架构——主菜单一个场景每个章节一个独立场景章节内再拆分逻辑子场景不一定对应 Unity Scene避免一个场景塞过多内容。这里要注意的是多场景加载要统一走异步加载接口由自研的 SceneLoader 组件控制进度条和 Loading UI不能直接调用 SceneManager.LoadScene否则场景切换时内存峰值会很难看。第二个决策是“存档的最小粒度”。推理游戏必须有非常细的变量记录比如“玩家是否已经看过某封信”“某个证物是否被组合过”“NPC 是否已经移动到另一个房间”。这些状态不能只靠保存场景内 GameObject 的启停来实现因为场景一旦重新加载所有运行时状态都会被清掉。我们采用了一个全局 GameState 对象以字典方式保存所有剧情变量的值存档时序列化整个 GameState并绑定时间戳和版本号加载时再根据这份数据重建所有场景内的状态。这个决策是整个项目架构里最重要的一环后面存档系统会详细讲。第三个决策是“叙事表现方式”。悬疑推理游戏需要大量特写镜头、物品高亮、对话人物的近景演出我们在前期就确定以 Cinemachine Timeline 作为主要的演出工具而不是为每个镜头手写插值代码。这条决策极大提升了叙事演出效率也让策划可以直接在 Timeline 上调整镜头焦段和节奏。2. 对话系统与线索系统悬疑游戏的核心玩法底座2.1 对话系统从写死到配置驱动悬疑推理游戏的对话不是简单的“你说一句我说一句”它包含人物头像、名字、语音、表情动画、剧情分支选项、条件判断满足某条件才出现某选项、以及对话结束后的回调事件。我们的第一个原型版本把对话硬编码在 C# 类里每条对话一个方法调试起来很灵活但策划完全没法自己调整。项目进入内容量产阶段后这种模式直接崩了——策划改一句话都要找程序迭代效率没法看。后来我们花了一周时间把对话系统重构为配置驱动。核心数据结构是一个 DialogueNode包含节点编号、讲话人、文本内容、语音资源引用、表情动画 ID、可选的选项列表。选项列表里每一项都带一个 ShowCondition指向 GameState 中的某个条件表达式。节点之间的流转支持顺序、跳转、分支三种模式用 GUID 而不是数组下标做引用避免在中间插入节点导致后续全部错位。这里有一个很典型的坑如果对话数据用 JSON 并使用 System.Text.Json 或者 Newtonsoft.Json 反序列化字段增删时要格外小心版本兼容。我们最后把对话配置全部做成了 ScriptableObject利用 Unity 的 Inspector 做可视化编辑并写了一个自定义 Editor 窗口来预览对话流程树。这比让策划直接改 JSON 友好得多也杜绝了格式错误导致运行时崩溃的问题。2.2 线索系统与推理面板的数据流线索系统需要同时服务玩法层和表现层。玩法上玩家拾取线索后该线索进入背包表现上线索通常对应场景里某个可交互物品的高亮状态和调查动画。我们做了一个 InteractableObject 基类所有可交互物体都继承自它并持有三个关键字段ObjectId、ClueId、InteractionRule。ObjectId 是场景内唯一标识ClueId 是线索配置表里的主键InteractionRule 则定义了这个物体在不同 GameState 下的表现行为。例如一个抽屉在玩家没有钥匙时交互结果是“上锁了”拿到钥匙后交互结果是“打开并获得物品 X”打开后再次交互则是“空无一物”。这套数据流在实际开发中非常实用表现层只根据 ObjectId 和当前 GameState 查询交互规则不需要关心推理逻辑本身让场景美术和程序开发可以并行。推理面板则是一个独立的 UI 系统负责展示所有已收集线索、人物档案、以及线索之间的关联关系。这个面板的数据来源不是背包里的物品列表而是 GameState 中维护的一个 ClueCollection每次玩家获得新线索时通过事件总线通知 UI 刷新。为了支持玩家推理时做“连线”“归组”这类操作我们在 UI 层使用了一个简单的拖拽组件并在拖拽结束时做一次规则匹配。如果匹配成功GameState 会写入一条新的推理记录并触发对应的演出片段。2.3 谜题系统需要抽象到什么程度市面上悬疑游戏的谜题类型很多密码锁、齿轮拼图、找不同、逻辑连线、物品组合、对话套话等等。如果每种谜题单独一套代码那维护成本会翻好几倍。我们的做法是抽象出一个 PuzzleBase 类定义 Initialize、CheckSolution、OnSolved、OnFailed 四个主要接口每种谜题作为一个子类实现。配置层上每道谜题都是一个 PuzzleConfig ScriptableObject里面包含谜题类型、对应的场景交互点、可能需要的道具 ID、以及解谜成功后的奖励线索 ID。运行时有一个 PuzzleManager 负责统一管理当前激活的谜题接收来自玩家操作的事件把操作结果转发给当前 PuzzleBase 子类做判断。这么做的好处是新增一种谜题只需要写一个新的 PuzzleBase 子类和对应的配置资产不需要改任何现有流程。项目后期增加了四五种谜题类型几乎没有引入过回归 Bug。有一点要特别提醒谜题 UI 与场景交互经常互相干扰。比如玩家正在解一个密码锁这时候如果触发了一个 NPC 对话界面层级就会乱掉。我们的解决方案是引入一个 UIStack 管理器所有全屏或者模态 UI 在打开时都向栈里注册关闭时从栈里弹出。任何新的交互请求先检查当前栈顶是否允许被覆盖不允许的话暂时存入队列等待模态 UI 关闭后再执行。这套机制虽然实现很简单却是保证交互不乱套的功臣。3. 存档系统叙事分支游戏的生命线3.1 存档结构设计纯数据存档 时间戳 版本号悬疑推理游戏的存档和动作游戏有很大不同。动作游戏的存档可以只保存关卡进度和角色属性但推理游戏必须保存成百上千个剧情变量的状态否则玩家读档后会看到各种逻辑矛盾比如人都消失了证物还在背包里。我们的存档以一整份 JSON 为最小单位包含以下部分SaveVersion存档结构版本号用于存档兼容和迁移Timestamp存档时间用于 S/L 界面排序ChapterId 和 StepId当前进度位置GameStateDictionary所有剧情变量的字典快照InventoryData背包物品的完整列表ObjectiveData任务日志状态各章节场景内的特殊状态记录例如“某房间门是否打开”“某物体是否已调查”这里有个设计取舍我们选择纯数据存档不保存场景对象的无损快照。也就是说读档时只恢复数据层的状态再根据数据层状态去驱动场景内对象的表现。这样做最大的好处是存档体积小、兼容性强即使某个场景在后续版本里被改了结构老存档依然能正确读出来。缺点是加载后必须有一套“场景状态重建机制”对每个可交互物体在 OnEnable 时执行一次 RefreshByState从 GameState 里读取自己当前应有的状态。3.2 剧情分支管理全局变量表 事件监听剧情分支管理的核心是全局变量表。我们用了一个枚举集合定义所有剧情变量内部用 HashSet 或 Dictionarystring, bool/int 存储值。每次剧情推进时由 LogicTrigger 统一写入变量并广播变更事件。UI 和场景对象通过监听变量变更事件来自动更新表现而不是每帧去轮询。这套设计听起来简单实战里有个容易翻车的地方变量的写入顺序。比如“拿到钥匙”和“打开抽屉”这两个事件如果因为代码顺序问题先写了“抽屉已打开”再写“拿到钥匙”一旦中间有异常存档里可能出现“钥匙还在背包但抽屉已经空了”的矛盾。所以我们给所有 LogicTrigger 加上了依赖声明每个触发器执行前必须声明它依赖哪些变量处于什么状态执行后它会设置哪些变量。启动时用一个拓扑排序器检查所有触发器之间的依赖环如果有环就在编辑器里直接报错。这个机制在项目后期帮我们抓到了两个会导致软锁的剧情 Bug。3.3 多结局与回溯机制的实现多结局是悬疑推理游戏的标配。我们的项目设计了四个主要结局和若干小结局结局分支取决于一系列关键推理变量的取值组合而不是单一的最终选项。实现上我们在 GameState 里维护了一个 EndFlagScore 字典每个关键推理节点会累加不同结局倾向的分数。最终章开始前系统读取所有分数选择分数最高的结局作为可进入分支。这个方案的好处是结局的解锁条件对玩家来说是隐性的不会因为一句关键对话选错就彻底错过某个结局玩家体验更自然。回看功能方面我们做了一个结局解锁图鉴每个结局对应一组“已解锁条件提示”玩家可以查看自己达成或未达成的推理关键点。这样既保留了重玩价值也不会因为剧透破坏第一遍的体验。4. 场景演出与摄像机让玩家走进故事4.1 摄像机与镜头语言的实现方案悬疑推理游戏很像互动电影镜头语言直接决定叙事氛围。我们放弃了单一跟随摄像机的方案改用 Cinemachine 的虚拟相机系统。每个章节里预先配置多个虚拟相机常规探索视角、对话近景、物品特写、以及走廊监控式的固定机位。通过 Cinemachine Brain 的优先级切换我们可以非常自然地推动镜头从探索状态进入对话状态不需要手写插值。物品特写这个环节有点讲究。玩家点击一个可疑物品时镜头要快速推到物品上方并稍微旋转一个角度给玩家一种“仔细端详”的感觉。这个动作我们用一个专门的 InteractCamera 虚拟相机完成开启时设置 LookAt 为目标物品并启用一个小幅度 PerlinNoise 噪声模拟手持呼吸感。热词里提到的 PerlinNoise 正好派上用场——Cinemachine 的 Noise Profile 本质上也是噪声算法合理调节 Frequency 和 Amplitude 可以让特写镜头显得很自然不会死板地固定在某个角度。4.2 Timeline 演出与任务指引的配合剧情动画我们统一用 Timeline 制作但有一个团队内部约定所有 Timeline 必须通过 GameState 的变量监听来驱动不能在 Timeline 里直接硬编码打开某个 UI 或播放某段音效最多只能发事件。这样做的原因是Timeline 是表现层而游戏逻辑在数据层。如果 Timeline 里直接修改游戏逻辑一旦玩家在演出过程中打开菜单或者触发跳过逻辑状态就会和数据层脱节。任务指引系统相对简单用的是经典的三元组目标 ID、目标描述、目标位置。每次 GameState 变化时如果涉及到当前任务的更新ObjectiveManager 会发出通知UI 左上角的任务栏会更新文本和追踪标记。为了避免导航线穿墙这种尴尬效果我们用的是“屏幕边缘箭头 小地图标记”的组合而不是 3D 寻路导航线。4.3 对话演出与 UI 的交互节奏对话演出是整个项目里最容易显得“廉价”的部分。如果只是立绘 文本框交替出现玩家的沉浸感会大打折扣。我们做了一套简单的对话演出控制器支持逐字打字机效果、停顿指令、自动翻页、以及对话过程中的镜头偏移。打字机效果不是每帧简单截取字符串而是用协程逐字显示文本并支持在文本中插入 wait0.5、之类的标记让策划可以控制读句的节奏。UI 交互上我们遵循一个原则任何时候玩家按下确认键响应必须即时。哪怕是打字机效果还没有播完按下确认也要立刻完整显示当前句再按一次才进入下一句。这个细节初看不起眼但实测下来非常影响手感。另外在对话过程中移动、旋转镜头等操作会被锁住但打开系统菜单始终是被允许的这需要 UGUI 的输入模块做一层输入分发控制。5. 性能优化与渲染细节中后期的主程日常5.1 UI 性能优化合批、图集与字体悬疑推理游戏有大量的 UI 界面对话、背包、线索、系统设置、章节切换UI 性能做不好会直接拉低帧率。我们的 UI 优化主要做了三件事图集规划、字体处理、以及动静分离。图集规划上所有 UI 图素必须打进图集Sprite Atlas不允许散图直接挂到 UI 上。我们按界面功能拆成多个图集对话专用一个、背包线索一个、通用组件一个每个图集大小控制在 2048 以内避免移动端显存占用过高。这里有个容易踩的坑如果一个图集引用在场景中没有被打包切换场景时会出现 UI 图片闪白。解决方案是让所有图集进入 Always Included或者在启动时统一加载到 Resources 里。字体方面TextMeshPro 使用动态字体时要注意字体回退。中文文本量大的对话界面如果动态字体的 Atlas 尺寸不够大会出现文字越打越糊的情况。我们为对话和剧情文本单独分配了 4096 的 Atlas 尺寸并在打包时用 Font Asset Creator 预烘焙了项目里常用字的前 3500 字。这个预烘焙操作把对话界面的运行时字体重建率降到了几乎为零。动静分离是指把常驻 UI 和动态刷新 UI 分开打 Canvas。常驻的 HUD 和背景层放一个静态 Canvas打开菜单时只刷新内容区域避免整个界面重建网格。每次打开背包时我们只更新内容区的子物体而不是重新实例化整个背包界面。这一条做得好的话可以明显减少打开界面时的卡顿。5.2 场景加载、内存与资源管线的优化项目的每个章节场景大小差异很大有些线性流程场景要加载上百个物件。我们统一使用 AssetBundle 做资源管理并按章节拆分 Bundle 粒度每个章节一个 Bundle公共资源和 UI 单独打包。加载流程上先加载公共 Bundle常驻内存不释放再加载章节 Bundle进入该章节时异步加载进度条显示的是 Bundle 加载进度和场景 Asset 加载进度的加权和离开章节时卸载非公共 Bundle并调用 Resources.UnloadUnusedAssets 清理引用这套方案在 PC 端问题不大但在移动端仍然会遇到小内存设备的压力。我们的应对措施是严格限制同屏物件数量把过大的场景拆成多个子场景通过门、走廊等自然分隔做局部加载。另一个经验是阴影贴图在移动端尽量用 2048 以下光照贴图压缩格式用 ASTC特别是低端安卓机上阴影质量和高光质量该降就降。热词里提到 Unity 阴影问题我想说大部分场景里的阴影闪烁和漏光都不是 Shader 的问题而是阴影距离和级联阴影参数没有按场景尺寸调好这个需要每个场景单独测不能套一个全局参数走天下。5.3 烘焙光照、后期效果与画质分级画面表现上悬疑推理游戏需要比较强的光影氛围。我们室内场景全部使用烘焙光照动态物体用 Light Probes部分需要动态阴影的角色单独加一个实时平行光并且只影响角色层。烘焙光照贴图的参数挺折腾光照贴图分辨率、间接强度、反弹次数、以及 UV2 是否展开了。有时候场景没 UV2烘焙出来一片黑排查后发现是模型导入设置里 Generate Lightmap UVs 没勾。后期效果用了 Post Processing Stack v2。颜色分级Color Grading、泛光Bloom、环境光遮蔽Ambient Occlusion和暗角Vignette是悬疑氛围的核心泛光强度不能太高否则会让暗场景显得浑浊。移动端我们关闭了环境光遮蔽并且把泛光降到最低档因为移动端 GPU 的 fillrate 很吃紧。画质分级做得比较粗PC 端最高画质开全特效移动端根据设备内存和 GPU 型号自动选择低或中画质。我们没有做细粒度的手动画质档位因为这个游戏类型对帧率的要求没有竞技游戏高稳定在 30 帧以上就不会影响体验。6. 工具链与协作流程主程的另一半工作6.1 对话编辑器、谜题配置工具与自定义 Inspector团队规模不大的时候主程除了写游戏逻辑还要承担相当一部分编辑器工具开发。我们做的最值得的工具是一个对话编辑器窗口。它不仅能编辑对话树还能直接在编辑器里模拟运行分支条件查看某个节点在当前 GameState 下是否可见。这个工具让策划在出文本内容的同时就能自查逻辑减少了大量测试反馈往返。谜题配置工具相对简单是一个 Wizard 窗口输入谜题类型、场景交互点、谜题参数后自动生成 PuzzleConfig 资产并注册到章节流程里。相比手动创建资产再填字段这种方式能避免很多低级错误比如场景交互点的 ObjectId 写错、奖励线索 ID 不存在等等。自定义 Inspector 方面我们为 InteractableObject 做了场景内预览功能。编辑模式下选中一个可交互物体时Inspector 下方会出现一个“模拟 GameState”区域输入不同的变量值后场景中的物体表现会实时更新。这个工具在验证“同一个物体在不同剧情阶段的表现”时非常高效美术和策划不用频繁启动游戏就能检查表现。6.2 文本导入、多语言与版本管理对话文本如果直接让策划在 ScriptableObject 里填翻译和排版会非常痛苦。我们做了文本导出/导入工具支持把项目内所有对话和 UI 文本导出为 CSV策划和本地化同学在 CSV 里维护再导回项目中生成语言资产。这个流程在项目接近上线的本地化阶段帮了大忙四国语言在一个星期内全部灌入没有为翻译单独写一行代码。版本管理用的是 Git LFS。美术资源体量大必须用 LFS 管理否则仓库体积会失控。我们约定场景和 prefab 允许冲突合并且使用 Unity 的 YamlMerge 作为合并工具但代码层面必须严格要求单人单模块避免多人同时改同一个脚本。还有一个团队规范所有配置资产的 Inspector 字段不能直接改 GUID因为 GUID 是资产引用的核心一旦改了场景里的引用全断排查起来极其耗时。6.3 自动化构建与多渠道打包的踩坑自动化构建用 Unity 命令行批处理实现。我们搭了一个简单的构建脚本支持 PC、Android、以及抖音侧边栏小游戏和微信小游戏这几个主要目标平台。构建脚本里封装了版本号注入、AssetBundle 构建、启动场景替换、以及平台相关后处理步骤。踩过的坑有几个一是 Android 打包时的 Gradle 配置Unity 版本和 Gradle 版本要配套否则构建报错会让人一头雾水二是 AssetBundle 的变体管理如果同一个资源被多个 Bundle 引用要开启 Deterministic Asset Bundle 并统一依赖打包避免重复资源被多次打进包体三是抖音侧边栏和微信小游戏这类平台本质上是 WebGL/小游戏环境很多时候不能用完整的 C# 反射和文件 IO需要针对这些平台写适配层。比如文件存档在小游戏平台上要改成用平台提供的存储接口不能直接用 File.WriteAllText。7. 上线前的排雷清单那些容易忽略又致命的细节7.1 常见问题速查表整理一份我们项目里真实出现过的问题清单按模块归类方便大家对照排查问题现象可能原因解决方案对话选项界面无法弹出UIStack 顶层的模态界面未关闭检查所有调用 OpenUI 的地方是否成对调用 CloseUI读档后场景物体状态不对Scene 对象的 RefreshByState 未实现或遗漏所有 InteractableObject 必须在 OnEnable 时调用状态重建切换场景后内存持续上涨场景资源没有卸载干净使用 Addressables/AssetBundle 时检查引用计数添加卸载日志阴影闪烁或漏光级联阴影距离设置不对或 Lightmap 参数问题按场景尺寸单独调整 Shadow Distance检查 UV2小游戏平台存档丢失使用了 File IO 而非平台存储接口写平台适配层切换存档读写实现UI 中文乱码动态字体 Atlas 尺寸不够或者字体 Fallback 配置缺失预烘焙常用字并配置 Fallback 字体资产长时间游玩后帧率下降对象池使用不当导致泄漏或频繁 GC用 Profiler 抓 Hot Path检查生成对象是否放回池中7.2 平台适配从 PC 到移动端再到小游戏多平台发布是Unity项目的常态。我们一开始只准备做 PC后来加了移动端最终又进了抖音侧边栏和微信小游戏渠道。这个过程中最痛苦的不是渲染差异而是输入和存档差异。PC 上用鼠标点击交互移动端要用触屏小游戏则要兼容浏览器的安全区。我们的解决方案是抽象了一个 InputAdapter统一提供点击、长按、拖拽、返回键等语义化输入接口底层根据平台不同分别实现。UI 适配也踩了不少坑。悬疑推理游戏的任务栏、对话文本、背包网格在窄屏上很容易挤成一团。我们用 Unity 的 Canvas Scaler 以宽度适配为主针对平板和 PC 大屏额外做了 SafeArea 适配。小游戏平台要特别注意刘海屏和安全区不然按钮会顶到屏幕边缘点不到。7.3 性能 Profile 实战案例项目中期接到测试反馈说某个章节场景在低端安卓机上帧率掉到 15 帧以下。我用 Profiler 抓了一轮定位到一个很典型的问题场景里有大量可交互物品每个物品都在 Update 里做射线检测和描边高亮CPU 消耗被这些高频检测打爆了。优化方案分两步第一步把高亮描边的判断改成只在玩家靠近时触发用 OnTriggerEnter/OnTriggerExit 替代每帧距离检测第二步把可交互物品的更新频率做分级管理屏幕中心附近的物品每帧检测其他物品每 0.2 秒检测一次。这两步优化直接把该场景的 CPU 耗时降了一半以上。另一个案例是对话中出现卡顿抓包发现是每次对话加载时都会实例化大量 UI 组件。改成 UI 对象池后对话打开耗时从 300ms 降到了 50ms 左右。8. 项目复盘如果让我重做一遍会改什么做完整整一个项目周期回看当初的架构决策有几个地方如果重来我会调整。第一会把资源管理直接上 Addressables而不是自己封装 AssetBundle。自研方案在项目初期确实灵活但中后期随着资源依赖越来越复杂引用计数和依赖管理占用了不少维护精力。Addressables 的弱引用管理和自动依赖加载可以省掉这部分成本。第二会更早地引入自动化测试。推理游戏的剧情分支和变量组合非常多纯靠人工回归测试根本覆盖不过来。我们后期补了一些 PlayMode 测试但只覆盖了核心流程。如果项目启动时就搭建好基于场景的自动化冒烟测试每次改剧情配置后跑一遍能省下大量的修 Bug 时间。第三路径与工具的统一要在团队里更早形成共识。像字体预烘焙、图集规范、场景检查清单这些东西如果美术和策划能从项目第一天就遵守后期返工会减少很多。最后再分享一个小技巧给所有场景和 UI 界面都加上一个开发者调试快捷键可以在运行时查看当前 GameState 的全部变量值也可以直接修改任意变量来跳剧情。这个功能从开发第一天起只花了半天时间做但整个项目周期里它帮我们节省的时间绝对是数以周计的。每次测试报 Bug我第一件事就是用调试面板把 GameState 拉到出问题的状态立刻复现定位速度极快。如果你也在做分支剧情类游戏这个调试工具值得优先做。