Unity3D RPG 从零搭建：战斗、场景切换与存档

把一个 RPG 从空项目推到能走、能砍、能换场景、能读档的状态是很多人入行的第一道坎。我第一次做这件事的时候光是为什么我的角色挥刀没有伤害就卡了整整一个周末最后发现是动画事件挂在了一个被禁用的骨骼节点上。这篇就聊 Unity3D 下 RPG 的初始环境搭建、战斗系统、场景切换与存档这四件事从工程目录怎么分、战斗数值按什么口径算到异步加载怎么不卡帧、存档怎么写到一半断电也不炸文件。适合刚上手 Unity3D 想做完整 RPG 循环的朋友也适合已经能写点脚本、但系统一多就乱成一锅粥的同学。我不打算讲什么是 GameObject这种内容默认你能看懂 C# 和基本的引擎面板重点放在那些文档里不写、但你一定会撞上的地方。1. 开局三件事版本、目录、场景1.1 引擎版本与渲染管线的取舍逻辑第一个决策不是写代码是选版本。我的建议很明确用官方的 LTS 长期支持版别追最新预览版。原因不在于新版本不好而在于 RPG 这种项目周期长、依赖库多预览版里某个 API 签名变动可能让你三天前写的战斗模块全部编译报错。LTS 版本经过大半年的社区验证你遇到的坑基本都有人踩过搜索引擎里能找到答案这个隐性成本比新特性值钱得多。渲染管线的选择同样要想清楚。内置管线胜在资料多、任何老旧教程都能直接照抄但光照表现和后期效果明显吃力通用渲染管线URP在移动端性能友好、光照配置直观代价是材质升级后部分内置着色器不可用一些老插件会直接紫屏。我这边做的是中小规模的 RPG最终选了 URP因为角色数量多、需要批量合批URP 的 SRP Batcher 在同屏几十个怪的场景里收益很实在。如果你的项目目标是纯 PC 单机、画面要求高、又不想折腾管线迁移内置管线也不是不能选只是后期想换会很痛。提示管线一旦定了就别中途改。真要改务必在美术资源大规模生产之前否则几百个材质的升级返工能让人怀疑人生。项目模板上别用带一堆示例资源的模板开局选最干净的空模板然后自己按需安装包。开箱模板里的示例场景、示例脚本、示例输入配置后期清理起来比重建还费劲尤其是那套示例输入配置会和你后面自己配的按键映射打架。1.2 目录结构与工程规范先立规矩再写代码我见过太多做到第三个月就找不到文件的项目。目录规范这件事第一天不做后面就是灾难。我的做法是在 Assets 下建一个下划线开头的项目根目录把所有自己写的东西塞进去和引擎、第三方资源物理隔离Assets/ ├── _Project/ │ ├── Scripts/ │ │ ├── Core/ // 启动、全局管理器、事件总线 │ │ ├── Combat/ // 战斗相关 │ │ ├── Save/ // 存档 │ │ ├── SceneFlow/ // 场景加载 │ │ └── UI/ │ ├── Art/ │ │ ├── Characters/ │ │ ├── Environment/ │ │ └── VFX/ │ ├── Audio/ │ ├── Data/ // 配置表、ScriptableObject 资产 │ ├── Prefabs/ │ ├── Scenes/ │ └── Settings/ ├── ThirdParty/ // 外部资源永不修改 └── Plugins/这个结构的核心思想只有一个我的东西和别人的东西永远不混放。下划线前缀保证_Project永远排在资源列表最上面找东西时不用滚动。ThirdParty目录里的内容我一个字符都不改需要调整就在外面包一层适配脚本这样将来升级库版本时直接整个目录替换不会丢改动。另一件值得第一天就做的事是程序集定义Assembly Definition。把 Core、Combat、UI 拆成独立程序集好处有两个一是编译速度改一行 UI 代码不用把整个项目重编二是强制约束依赖方向——UI 可以引用 CombatCombat 绝对不能引用 UI。这条约束会在你写到第二十个小时的时候救你一命因为它从编译期就阻止你把表现逻辑塞进战斗计算里。命名上我用的规则很土但很有效脚本名等于类名一个文件一个公开类预制体名和主脚本名一致场景名用英文加编号Level_01。听起来像废话但当你在搜索框里输入Player弹出十七个结果的时候就会感谢当初那个坚持命名的自己。1.3 场景清单与最小可玩闭环RPG 的场景不止是关卡。我一开始只建了一个测试场景结果做到一半发现角色数据需要跨场景保留这件事根本没有落点只能推倒重来。正确的做法是在开工时就规划出这条链路场景职责关键内容Boot全局初始化只加载一次常驻管理器、存档读取入口、设置加载MainMenu主菜单、新建/继续游戏UI 交互不承载任何战斗逻辑Level_01第一张可玩地图出生点、敌人、可交互物Level_02第二张地图用于验证跨场景数据传递为什么要有一个独立的 Boot 场景因为 RPG 里有一批对象需要永远活着——背包数据、玩家属性、音频管理、场景加载器。把这些做成预制体放在 Boot 场景里用DontDestroyOnLoad保护起来切场景时它们不受影响。如果直接在主菜单里做初始化一旦玩家从主菜单反复进出初始化逻辑就可能执行多次产生重复的监听器、重复的单例表现为打一下怪掉两次血这种灵异现象。最小可玩闭环的判定标准我给一个很具体的清单角色能用键盘移动、能攻击、敌人有血量并会对玩家造成伤害、敌人死亡后消失、能从第一张图走到第二张图并保留当前血量、退出游戏重进能恢复到存档位置。这六条全部通过才叫骨架跑通了可以开始往里填内容。少任何一条后面加系统都会带着隐患。2. 战斗系统先数据后表现2.1 属性结构与伤害公式的口径设计新手最容易犯的错是先做特效和动画最后才想起来伤害怎么算。我的顺序永远反过来先把数据结构定下来再让表现去消费数据。因为表现是随时可以换的换模型、换特效、换动画而数值口径一旦被后续几十个技能依赖改动成本会指数级上升。角色的战斗属性我用一个可序列化的结构体承载注意这里是用结构体而不是类因为它需要频繁拷贝快照比如中毒前的属性这种临时状态[System.Serializable] public struct CombatStats { public int maxHp; public int maxMp; public int attack; // 物理攻击 public int defense; // 物理防御 public float critRate; // 暴击率 0~1 public float critDamage; // 暴击倍率默认 1.5 public float attackSpeed; }伤害公式是最需要反复琢磨的地方。我试过三种说说各自的坑。第一种是纯减法伤害 攻击 - 防御。直观、好理解、玩家一眼能算明白。问题是当防御接近攻击时伤害趋近 0会出现打不动的挫败感防御超过攻击还会算出负数得强制Mathf.Max(1, ...)兜底然后数值策划就得小心翼翼地控制防御成长曲线非常不方便。第二种是纯百分比减伤减伤率 防御 / (防御 K)。这个公式的好处天然不会出现负数和零伤害防御的收益是递减的越堆收益越低天然抑制全点防御的极限流派。K 是常数控制减伤曲线的陡峭程度K 取 100 时100 点防御对应 50% 减伤。第三种是我最终用的混合式public static int CalculateDamage(CombatStats attacker, CombatStats defender, float skillMultiplier 1f) { float mitigation defender.defense / (defender.defense 100f); float raw attacker.attack * skillMultiplier * (1f - mitigation); bool isCrit Random.value attacker.critRate; if (isCrit) raw * attacker.critDamage; return Mathf.Max(1, Mathf.RoundToInt(raw)); }混合式的意思是减伤用百分比曲线保证平滑但结果先取整、再做最低值兜底。Mathf.Max(1, ...)保证任何情况下至少有 1 点伤害玩家永远不会遇到打了等于没打。取整放在乘完所有系数之后而不是在中间步骤取整——中间取整会产生累计误差一个 1.4 倍技能加成可能因为提前取整变成 1.3 倍的实际效果数值表就对不上了。注意暴击判定用Random.value critRateRandom.value返回 [0,1] 闭区间理论上等于 1 的情况极罕见实际不影响。但如果你自己实现随机函数务必确认区间是左闭右开还是双闭这个细节在暴击率设成 1.0必暴的时候会暴露出来。数值口径定完还要定一件事伤害是即时结算还是延迟结算。即时结算就是按下攻击键瞬间扣血延迟结算是在动画的攻击帧触发。必须选延迟否则会出现角色还在抬手怪已经死了的诡异画面。这就要用到动画事件或者时间轴回调具体放在 2.3 讲。2.2 用状态机管住角色行为RPG 角色的行为本质上是有限的几个状态之间的迁移待机、移动、攻击、受击、死亡。不用状态机硬写 if-else 的后果是代码会迅速膨胀成一棵谁也不敢碰的嵌套判断树改一个地方崩三个地方。我第一版就是那么写的最终Update里有四十多行嵌套加个闪避需求花了整整一天。我的做法是用一个极简的枚举状态机不引入任何第三方框架因为对这种五六个状态的角色来说重型状态机框架反而是负担public enum ActorState { Idle, Move, Attack, Hurt, Dead } public class ActorStateMachine { public ActorState Current { get; private set; } ActorState.Idle; public event System.ActionActorState, ActorState OnStateChanged; private readonly System.Collections.Generic.HashSetActorState _locked new(); public bool CanTransition(ActorState next) { if (Current ActorState.Dead) return false; // 死了不接受任何迁移 if (_locked.Contains(Current)) return false; // 当前状态是不可打断的 if (next ActorState.Hurt Current ActorState.Attack _locked.Contains(ActorState.Attack)) return false; return true; } public void Transition(ActorState next) { if (next Current) return; if (!CanTransition(next)) return; var prev Current; Current next; OnStateChanged?.Invoke(prev, next); } public void Lock(ActorState s) _locked.Add(s); public void Unlock(ActorState s) _locked.Remove(s); }这里有几个设计决定值得解释。为什么死亡是不可逆的硬编码因为复活应当走独立的流程重新初始化整个角色对象而不是把状态从 Dead 改回 Idle。如果允许从 Dead 迁移出去你会遇到角色死了但动画还在跑、碰撞体没关、还被索敌这一整串问题。把死亡做成终态复活时直接重建逻辑最干净。为什么要锁定机制因为攻击状态通常带两段不可打断的窗口——前摇和后摇。前摇不能被移动打断否则可以靠移动取消前摇无伤输出后摇也不能随便打断否则动作没有重量感。锁定用集合而不是布尔值是因为可能存在多重锁定比如攻击中同时也被剧情锁定操作解锁要按顺序来用布尔值会互相覆盖。为什么用事件而不是让外部轮询状态动画控制器、特效系统、UI 血条都需要知道状态变化如果让它们每帧去if (state Attack)逻辑会散落各处且时序不可控。事件驱动可以保证状态一变化所有订阅者按注册顺序收到通知顺序确定调试时好定位。具体的攻击流程就是按下攻击键先检查CanTransition(Attack)通过则进入攻击状态、锁定、播放攻击动画动画到攻击帧通过事件回调执行伤害判定动画结束解锁、回到 Idle。这套下来行为是收敛的不会出现状态互相打架。2.3 命中判定攻击盒体与时间窗口这一节是最容易出 bug 的地方。我列几个我踩过的具体坑顺便讲正确做法。坑一用碰撞体触发判定。很多人第一反应是给武器挂一个 Collider设成触发器靠OnTriggerEnter判定命中。问题在于物理引擎的触发检测依赖刚体和帧率快速挥刀时武器可能一帧从敌人身前扫到身后中间完全检测不到这叫穿透。而且触发回调的执行顺序不确定同一帧打两个敌人时伤害结算顺序随机如果涉及死亡掉血这种联动结果会不稳定。正确的思路是几何查询 时间窗口。在攻击动画的命中帧主动做一次区域查询public class MeleeHitBox : MonoBehaviour { [SerializeField] private float radius 1.2f; [SerializeField] private float angle 100f; // 扇形张角 [SerializeField] private LayerMask targetLayer; public void PerformHit(CombatStats attacker) { var origin transform.position transform.forward * 0.6f; var hits Physics.OverlapSphere(origin, radius, targetLayer); foreach (var col in hits) { var toTarget col.transform.position - transform.position; if (Vector3.Angle(transform.forward, toTarget) angle * 0.5f) continue; var receiver col.GetComponentIDamageable(); if (receiver null) continue; int dmg DamageCalculator.CalculateDamage(attacker, receiver.Stats); receiver.TakeDamage(new DamageInfo(dmg, transform.position, DamageType.Physical)); } } }扇形判定用OverlapSphere拿候选再算夹角过滤比用碰撞体触发器可靠得多因为它是在确定的时刻做一次确定的查询和物理帧率无关。半径和角度这两个参数需要配合角色的攻击距离调单手剑大概 1.2 米半径、100 度扇形长枪可以到 2.5 米但角度收到 60 度重锤角度可以开到 140 度但半径小。这些数值别凭空拍先在场景里用OnDrawGizmos画出判定范围看着角色模型调调完再录下来对比手感这一步省不了。private void OnDrawGizmosSelected() { Gizmos.color new Color(1f, 0.4f, 0f, 0.35f); Gizmos.DrawWireSphere(transform.position transform.forward * 0.6f, radius); Gizmos.DrawRay(transform.position, Quaternion.Euler(0, -angle * 0.5f, 0) * transform.forward * radius); Gizmos.DrawRay(transform.position, Quaternion.Euler(0, angle * 0.5f, 0) * transform.forward * radius); }坑二同一个攻击命中同一目标多次。如果命中窗口持续时间大于一帧而你在Update里持续做查询一个敌人会被打三四次。解决办法是维护一个本次攻击已命中的目标集合攻击开始时清空private readonly HashSetIDamageable _hitThisSwing new(); public void BeginSwing() _hitThisSwing.Clear(); public void TryHit(IDamageable target) { if (!_hitThisSwing.Add(target)) return; // 已命中跳过 // ... 结算伤害 }坑三手感生硬。判定完全精确反而不好玩。真实手感需要三个东西命中帧前后各留一点容错判定窗口比动画看起来长两三帧、命中时有打击停顿命中瞬间把时间缩放拉到 0.05 持续 3~5 帧再恢复、以及受击方的击退和顿帧。这三样加起来玩家才会觉得刀砍进去了。我第一版没有打击停顿测的时候总觉得砍空气加上之后同一个动画的手感完全不同。提示打击停顿改的是Time.timeScale会影响所有基于时间的逻辑。如果你有 UI 动画或者加载进度条记得把它们改成unscaledDeltaTime否则停顿时界面也会卡住。攻击输入的处理也值得说一句。玩家按下攻击键的时机往往早于角色能接受输入的时机比如还在后摇里如果直接丢弃这次输入手感会很粘。正确做法是做一个短暂的输入缓冲把按键请求记下来在接下来 0.2 秒内如果状态变为可攻击就补执行这次攻击。这个改动只有十几行代码但手感提升非常明显是所有动作向 RPG 的标配。2.4 事件解耦让 UI 和特效自己来订阅战斗结算完成之后需要更新血条、播放飘字、播放受击特效、播放音效、判断死亡。如果把这些写进TakeDamage里这个方法会越来越长最后变成谁也不愿意碰的上帝方法。我的做法是定义一个全局静态事件总线专门转发战斗事件public readonly struct DamageInfo { public readonly int amount; public readonly Vector3 hitPoint; public readonly DamageType type; public DamageInfo(int amount, Vector3 hitPoint, DamageType type) { this.amount amount; this.hitPoint hitPoint; this.type type; } } public static class CombatEvents { public static event System.ActionIDamageable, DamageInfo OnDamageDealt; public static event System.ActionIDamageable OnActorDied; public static void RaiseDamage(IDamageable target, DamageInfo info) OnDamageDealt?.Invoke(target, info); public static void RaiseDeath(IDamageable target) OnActorDied?.Invoke(target); }这里把事件定义成静态的好处是不需要拿到任何引用就能订阅UI 面板在自己的OnEnable里订阅、OnDisable里退订和战斗系统零耦合。坏处是必须在OnDisable里退订否则对象销毁后事件还持有它的引用会引发空引用异常甚至内存泄漏——这是静态事件最经典的坑我在第一个项目里被它折磨了很久表现为切换场景后打怪报空指针。还有一个细节用readonly struct而不是类来传递伤害信息是为了避免每次攻击都产生一次堆分配。RPG 里战斗频率很高一秒几十次伤害结算如果每次都 new 一个类对象GC 会在几十秒后集中触发一次表现为周期性的掉帧。结构体是栈分配的没有这个问题。3. 场景切换别让加载毁掉体验3.1 为什么不能直接同步加载SceneManager.LoadScene(Level_02)这一行代码确实能切场景但它是同步阻塞的整个主线程卡在那里等资源加载完界面完全冻结。测试场景里资源少你感觉不到等地图铺满美术资源玩家就会看到画面定格两三秒像程序崩了一样。更麻烦的是同步加载会丢掉所有过场信息。RPG 的场景切换通常需要显示加载界面、展示当前章节名、淡入淡出、加载完成后把玩家放到正确出生点。这些都需要在加载过程中有帧可以执行同步加载把帧全占了。所以我的场景切换一律走异步加载 进度展示。核心是LoadSceneAsync返回的AsyncOperation配合allowSceneActivation false手动控制激活时机public class SceneLoader : MonoBehaviour { public static SceneLoader Instance { get; private set; } [SerializeField] private CanvasGroup loadingGroup; [SerializeField] private UnityEngine.UI.Slider progressBar; public string PendingSpawnId { get; set; } public bool IsLoading { get; private set; } private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; DontDestroyOnLoad(gameObject); loadingGroup.alpha 0f; loadingGroup.blocksRaycasts false; } public void LoadScene(string sceneName, string spawnId Default) { if (IsLoading) return; PendingSpawnId spawnId; StartCoroutine(LoadRoutine(sceneName)); } private System.Collections.IEnumerator LoadRoutine(string sceneName) { IsLoading true; yield return FadeCanvas(0f, 1f, 0.25f); // 淡入遮罩 var op UnityEngine.SceneManagement.SceneManager.LoadSceneAsync(sceneName); op.allowSceneActivation false; float shown 0f; while (op.progress 0.9f) { // 真实进度只到 0.9映射到 0~1 float target Mathf.Clamp01(op.progress / 0.9f); shown Mathf.MoveTowards(shown, target, Time.unscaledDeltaTime * 1.5f); progressBar.value shown; yield return null; } // 资源已就绪把剩余进度补满避免进度条卡在 90% while (shown 1f) { shown Mathf.MoveTowards(shown, 1f, Time.unscaledDeltaTime * 2f); progressBar.value shown; yield return null; } op.allowSceneActivation true; while (!op.isDone) yield return null; yield return FadeCanvas(1f, 0f, 0.25f); // 淡出遮罩 IsLoading false; } private System.Collections.IEnumerator FadeCanvas(float from, float to, float dur) { float t 0f; loadingGroup.blocksRaycasts to 0.5f; while (t dur) { t Time.unscaledDeltaTime; loadingGroup.alpha Mathf.Lerp(from, to, t / dur); yield return null; } loadingGroup.alpha to; } }几个关键点解释。op.progress最大只到 0.9。这是引擎的固有行为因为剩下 0.1 是场景激活阶段只有在allowSceneActivation true之后才会推进。所以映射进度时必须除以 0.9否则进度条永远停在 90%玩家会以为卡死了。这也是为什么加载界面通常要做假进度——真实进度到 90% 后用一小段平滑动画补到 100%让观感完整。为什么要MoveTowards而不是直接赋值因为op.progress的更新是跳跃的可能一帧跳 15%进度条直接弹过去观感很差。用固定速度追上去看起来才像加载而不是闪一下。为什么淡入遮罩在加载开始前因为加载过程中主线程有短暂卡顿资源解压如果先加载再遮罩玩家会看到一瞬间的画面冻结。先盖上遮罩再开始加载卡顿就被遮住了。这是一个几乎零成本但效果显著的技巧。3.2 出生点与跨场景数据传递切完场景后最经典的 bug 是玩家出现在场景中央或者直接从天上掉下去。原因是新场景加载后玩家对象需要被放到指定位置。我的方案是在目标场景里放若干个空物体作为出生点用名字标记public class SpawnPoint : MonoBehaviour { [SerializeField] private string spawnId Default; public string SpawnId spawnId; } // 场景加载完成后执行的代码 public class SpawnHandler : MonoBehaviour { private void OnEnable() { UnityEngine.SceneManagement.SceneManager.sceneLoaded HandleSceneLoaded; } private void OnDisable() { UnityEngine.SceneManagement.SceneManager.sceneLoaded - HandleSceneLoaded; } private void HandleSceneLoaded(UnityEngine.SceneManagement.Scene scene, UnityEngine.SceneManagement.LoadSceneMode mode) { if (mode ! UnityEngine.SceneManagement.LoadSceneMode.Single) return; var player GameObject.FindWithTag(Player); if (player null) return; var points FindObjectsOfTypeSpawnPoint(); var target System.Array.Find(points, p p.SpawnId SceneLoader.Instance.PendingSpawnId) ?? System.Array.Find(points, p p.SpawnId Default); if (target ! null) { player.transform.position target.transform.position; player.transform.rotation target.transform.rotation; } } }用sceneLoaded事件而不是在协程里直接设置位置是因为场景加载完成和对象初始化完成是两回事。如果在协程的while (!op.isDone)之后立刻设置位置新场景里的物理系统可能还没准备好位置会被物理引擎的碰撞解算推走。用事件回调能保证在场景所有对象Awake/OnEnable之后执行时序更可靠。至于跨场景的数据传递原则是场景之间不直接引用所有共享状态放在常驻的全局对象里。玩家血量、背包、任务进度这些数据全部挂在一个不销毁的GameSession单例上场景只负责展示不负责持有。这样即使玩家在一个场景里死了重开数据也可以选择保留或重置不会因为场景卸载而丢失。注意FindObjectsOfType在场景加载时调用一次问题不大但千万别放在Update里。这个 API 会遍历整个场景层级同屏对象上千时开销非常可观。如果是频繁查找改用注册表模式对象在OnEnable时把自己登记到一个静态字典里。3.3 加载过程中的资源管理异步加载还有一个容易被忽略的点旧场景的卸载和新场景的加载是同一个操作LoadSceneMode.Single会自动卸载旧场景。但如果你在旧场景里DontDestroyOnLoad了一些对象比如特效、掉落物容器它们会跟着走久了就堆成一堆。我的处理方式是给所有跨场景对象加一个统一的基类负责在合适的时机清理自己public abstract class PersistentObject : MonoBehaviour { protected virtual void Awake() { transform.SetParent(null); DontDestroyOnLoad(gameObject); } protected abstract bool ShouldSurvive(string newSceneName); }然后在场景加载事件里遍历所有PersistentObject把不该活过这次切换的直接销毁。听起来有点绕但比到处手动销毁可靠得多因为你能在一个地方看清所有常驻对象的生命周期。还有个性能上的小技巧如果两张地图共享同一套角色和 UI 资源可以在加载前用Resources.UnloadUnusedAssets清一次但要放在加载之后而不是之前——放在之前会把马上要用的资源也清掉反而增加加载时间。这个 API 会触发一次同步的垃圾回收大项目里可能卡几百毫秒最好配合加载界面使用。4. 存档系统从存什么到怎么安全地写4.1 存档边界什么该存什么绝对不存存档设计的第一原则不是技术是划清边界。我见过把整个场景对象序列化进去的方案结果存档文件几十兆读档还要三秒。正确的做法是只存必要且不可再生的数据。我的划分是这样的类别存不存理由玩家等级、经验、属性点存玩家投入的时间绝对不可丢当前血量/蓝量存影响读档后的战斗状态背包物品与数量存同上装备穿戴状态存同上已完成任务标记存靠它判断任务能否接取场景名 出生点 ID存用于恢复位置敌人当前血量不存读档后敌人重置满血玩家反而受益场景里掉落的临时物品不存会导致存档膨胀和数据不一致特效、音效状态不存纯表现无意义用数据类来承载全部字段必须是可序列化的基础类型或它们的容器[System.Serializable] public class SaveData { public int version 1; public long timestamp; // Unix 秒用于显示存档时间 public string sceneName; public string spawnId; public int level; public int exp; public int hp; public int mp; public System.Collections.Generic.ListItemStack inventory new(); public System.Collections.Generic.Liststring equippedIds new(); public System.Collections.Generic.Liststring completedQuests new(); public float playerX, playerY, playerZ; // 不用 Vector3避免序列化兼容问题 } [System.Serializable] public class ItemStack { public string itemId; public int count; }为什么坐标拆成三个 float 而不是直接存 Vector3因为Vector3的序列化依赖引擎内部实现不同版本之间字段可能变化而且用其他工具比如外部编辑器、云端校验读写时不好解析。拆成基础类型虽然难看但兼容性最好。经验是存档结构里只放基础类型和它们的容器一个引擎类型都不要放。这条规则能避免九成的换版本读不出档问题。另外警告一句绝对不要序列化 MonoBehaviour 的引用也不要存 GameObject 的实例 ID。这些 ID 在下次运行时会全部变化读出来就是一串无效引用。物品、任务、技能都用字符串 ID 表示读到档之后靠配置表去还原。4.2 序列化方案与安全写入序列化格式我选 JSON。二进制格式体积小、读取快但调试时读不出来JSON 用文本编辑器就能看出问题一眼定位对一个中小项目来说可维护性远比那几 KB 的体积重要。引擎自带的 JSON 工具对字典支持不好Dictionary不会正确序列化所以我的做法是数据结构里全用 List需要字典语义时在读档后自己转换public class SaveSystem { private static string PathFor(int slot) System.IO.Path.Combine(Application.persistentDataPath, $save_{slot}.json); public static bool Save(SaveData data, int slot) { try { data.timestamp System.DateTimeOffset.UtcNow.ToUnixTimeSeconds(); string json UnityEngine.JsonUtility.ToJson(data, true); string finalPath PathFor(slot); string tempPath finalPath .tmp; string backupPath finalPath .bak; System.IO.File.WriteAllText(tempPath, json); // 原子替换先转正再把旧文件挪成备份 if (System.IO.File.Exists(finalPath)) { if (System.IO.File.Exists(backupPath)) System.IO.File.Delete(backupPath); System.IO.File.Move(finalPath, backupPath); } System.IO.File.Move(tempPath, finalPath); return true; } catch (System.Exception e) { UnityEngine.Debug.LogError($存档失败: {e.Message}); return false; } } public static SaveData Load(int slot) { string path PathFor(slot); if (!System.IO.File.Exists(path)) { string backup path .bak; if (System.IO.File.Exists(backup)) path backup; else return null; } try { string json System.IO.File.ReadAllText(path); var data UnityEngine.JsonUtility.FromJsonSaveData(json); return Migrate(data); } catch (System.Exception e) { UnityEngine.Debug.LogError($读档失败: {e.Message}); return null; } } }这段代码里最重要的是先写临时文件再原子替换。直接覆盖原文件的风险是写到一半手机没电、或者玩家强杀进程文件会变成半截 JSON下次读档直接解析失败存档就废了。写临时文件、校验、再改名这个顺序保证你永远有一个完整的旧版本兜底。多花的那几毫秒换的是玩家几十小时进度的安全不亏。那个.bak备份也不是多余的。我在测试时故意用任务管理器杀掉进程验证过如果损坏发生在改名之前原文件还是完整的如果发生在改名之后.bak里还有上一份。读档时发现主文件读不出来就自动回落备份双重保险。提示Application.persistentDataPath在不同平台上指向不同位置而且可能被系统清理比如某些平台的缓存策略。如果项目对存档有更高要求需要额外做云端同步或者手动导出不要假设本地文件永久有效。4.3 版本号与后续兼容version字段是给未来的自己留的后路。游戏上线之后存档结构几乎一定会变——加新职业、加新装备栏、改属性算法。如果不做版本控制老玩家的存档读进来就会缺字段表现为属性全 0、背包空白。我的做法是每次结构调整就把version加一然后写一个迁移函数private static SaveData Migrate(SaveData data) { if (data null) return null; // 从 v1 到 v2新增了背包容量字段 if (data.version 2) { data.inventory ?? new System.Collections.Generic.ListItemStack(); data.version 2; } // 从 v2 到 v3玩家坐标改为场景相对坐标这里做一次性换算 if (data.version 3) { data.spawnId ?? Default; data.version 3; } return data; }关键点是迁移要能连续执行而不是只判断两个版本。老玩家可能从 v1 直接跳到 v3代码要能顺着 1→2→3 一路走下来。所以每一段迁移只负责从上一版到本版绝不跳步。这个习惯养成之后加字段几乎零成本。另外所有新增字段都要给默认值不能依赖读档时自动初始化——如果老存档里没有这个字段反序列化后它就是 null 或 0你得在迁移里显式补上。特别是 Listnull 和空列表在后续逻辑里表现完全不同null 会直接抛空引用。4.4 存档时机与自动存档设计什么时候存自动存档的时机选择直接影响玩家体验。我的策略是三类第一类是关键节点必存进入新场景、击败 Boss、完成任务、获得稀有物品。这几个时刻都是玩家不想重来的位置存了有安全感。第二类是周期兜底每三到五分钟存一次。防止玩家在野外跑了半小时突然崩溃进度全丢。但要注意别在战斗高潮里存因为存档的瞬间会有一点点卡顿最好在战斗结束后延迟十几秒再存。第三类是手动存档在菜单里给玩家一个明确的保存按钮。有些玩家就是喜欢自己掌控给他这个权利。具体实现上自动存档我用一个协程配合脏标记public class AutoSave : MonoBehaviour { [SerializeField] private float interval 180f; private float _timer; private bool _dirty; public void MarkDirty() _dirty true; private void Update() { _timer Time.unscaledDeltaTime; if (_timer interval || !_dirty) return; _timer 0f; _dirty false; SaveSystem.Save(GameSession.Instance.BuildSaveData(), GameSession.Instance.CurrentSlot); } }用unscaledDeltaTime是为了游戏暂停时也能计时但更稳妥的做法是让计时在游戏暂停时也走——很多游戏在菜单里停留很久出来就想让存档生效。注意存档写入是同步的文件 IO虽然有临时文件保护但如果存档内容很大比如十几兆在移动端会有明显的卡顿。真要优化可以用异步线程写文件但必须保证写完之后才允许下一次存档否则两次写入会互相覆盖。我用的是简单的写入中禁止再次写入标志位够用且不出错。5. 踩坑速查这些坑我一个个撞过来的5.1 高频问题速查表现象大概率原因排查方向攻击没伤害动画事件挂在了被禁用的节点上检查事件接收脚本所在的 GameObject 是否 Active一次攻击掉多段血命中窗口内重复判定加已命中目标集合攻击开始时清空切场景后 UI 消失UI 挂在旧场景下被卸载把 UI 根节点设成常驻切场景后角色瞬移出生点在场景加载完成后才设置用 sceneLoaded 事件设置位置读档后属性全 0结构变化但没做版本迁移加 version 字段并写迁移逻辑存档丢失覆盖写过程中被中断改用临时文件 原子替换加载进度条卡在 90%没处理 allowSceneActivation手动映射进度并补满打怪时报空引用静态事件没在 OnDisable 退订检查所有订阅点是否配对退订帧率周期性掉战斗逻辑频繁 new 对象改结构体、加对象池敌人打不死伤害被取整成 0加 Mathf.Max(1, ...) 兜底5.2 编辑器内正常、真机上出问题的典型差异这几处差异我每一个都踩过值得单独拎出来。路径大小写。编辑器在部分系统上对文件名大小写不敏感真机可能敏感。资源名随手写成Player_atk和player_atk混用编辑器里能加载打包后直接找不到资源。规矩是全部小写下划线从第一天就统一。帧率差异。编辑器里跑 200 帧真机锁 60 帧所有基于每帧做一点的逻辑都会变慢。比如用Update里累加来做动画插值、或者用帧数做计时真机上进度条会明显变慢。解决办法是全部改成Time.deltaTime驱动绝不用帧数当时间单位。文件权限。编辑器里Application.persistentDataPath是个普通目录随便读写某些平台上这个目录有额外限制外部直接访问需要用系统提供的接口。所以不要在代码里硬编码绝对路径一律用引擎提供的路径 API 拼接。日志性能。编辑器里Debug.Log几乎无感真机上高频打印日志能直接把帧率打下来。上线前把日志封装一层加个开关正式包只保留错误级别。5.3 调试技巧与工程习惯最后分享几个真正省时间的习惯。给每个系统留一个调试面板。我在场景里挂了一个隐藏的调试 UI按一个键调出来上面有给玩家加一万金币直接跳到第二关强制存档/读档杀掉所有敌人这些按钮。听起来是额外工作量但它让我测存档逻辑的时间从每次三分钟缩短到十秒。测二十次就回本了。善用自定义 Gizmos。攻击范围、出生点、敌人巡逻路径、触发区域全部画出来。所有为什么打不到的问题打开 Scene 视图看一眼就清楚了。花十分钟写画线代码能省掉几小时的瞎猜。状态机的当前状态要可见。角色头顶挂一个小标签显示当前状态枚举或者干脆在 Inspector 里做一个只读字段。我在调受击打断的时候因为看不到状态变化硬是加了二十几个日志才定位到问题事后发现做个可视状态标签十分钟就能解决。版本控制从第一天开始并且忽略正确。提交前确认Library、Temp、Logs、obj这些目录都在忽略列表里。我见过有人把Library提交上去仓库直接涨到几个 G清理起来非常麻烦。另外场景文件冲突几乎无法合并多人协作时约定好每人负责的场景避免同时改同一个。最后一条也是最重要的把最小可玩闭环尽快跑通再开始美化。我第一个 RPG 项目在美术上花了两个月结果战斗系统和存档完全没做做到最后发现数据流设计有问题所有美术资源都要重新挂一遍。先用胶囊体和方块把玩法跑通确认数据流、状态机、存档结构都合理了再往里填皮。顺序反过来返工的成本是数倍的。现在我的习惯是每做一个新系统先写一个丑但完整的版本跑通之后再花时间打磨。上面这套战斗、场景、存档的骨架我已经在三个小项目里复用过了改的只是数值和资源结构一次都没动过。这也是我为什么建议先把这套东西吃透——它不是一个教程是一个可以直接搬走的地基。