简介这份Unity3D跑酷类小游戏源码面向有C#与Unity基础的初学者和独立开发者可用于完整走通一款3D跑酷游戏的开发流程。压缩包共5428个文件、约18.22MB其中197个cs脚本承载角色控制、碰撞检测、得分与场景切换等逻辑8个prefab、22个asset与334个meta组织场景与预制体29个mat、24个shader负责材质与渲染表现46个png与3个ttf补齐美术与界面素材bin、info等则属于工程缓存与导入记录。已有2787人学习下载工程结构较为完整可在编辑器内直接运行并逐层拆解。读者能从中获取CharacterController驱动的移动跳跃实现、基于Collider的障碍碰撞判定、Animator状态机下奔跑与落地的动画衔接以及Unity UI搭建的计分板与提示界面并借SceneManager理解多关卡切换的组织方式适合作为熟悉面向对象设计与模块化代码复用的练习项目。1. 从一条永远跑不到头的赛道说起我见过太多人下载完一份 Unity3D 跑酷类小游戏源码第一反应是把角色模型换成自己的贴图换一套就能上架。真打开工程之后才发现赛道根本不是一条做好的长条而是由几十段预制体在角色身后拆、身前拼跑得越远拼得越多角色也不是刚体推着走而是一个 CharacterController 加着自定义的重力常量障碍物和金币从来没被 Destroy 过全在几个 Queue 里转圈复用。这套结构说穿了就四块三轨道切轨的角色控制器、按段拼接再回收的无限赛道、带权重表的障碍与金币生成器以及一层很薄的状态机管着待机、跑动、撞击、结算。它适合两类人一类是刚学完 Unity 基础、想跑通一个完整玩法闭环的新手另一类是手里有个美术资源包想找一套现成的生成回收框架往上套的老手。下面按能干什么、怎么跑、怎么改的顺序把这份源码从工程骨架拆到二次开发接口。2. 工程骨架与启动链路从打开工程到跑通第一关一份跑酷工程的复杂度八成不在玩法本身而在它怎么把无限这件事伪装成有限。打开工程先别看 Scripts 文件夹里有多少个脚本先看场景有几个、Persistent 场景里挂了什么基本就能判断这套代码是能改的还是只能看的。2.1 目录结构与场景划分合格的跑酷工程目录通常长这样这份源码也基本遵循同样的组织方式目录存放内容改动频率Scenes/Main 主场景、Boot 启动场景低Scripts/Player/角色控制器、输入抽象、动画驱动中Scripts/Track/分段生成器、段池、段预制体逻辑中Scripts/Gameplay/障碍、金币、道具、碰撞判定高Scripts/Core/游戏状态机、分数、存档、事件总线低Prefabs/Track/各类赛道段预制体直道、弯道、跳台高Art/、Audio/模型、贴图、音效高场景划分是关键。常见做法是两个场景Boot 场景只挂一个常驻的 GameManager 和音频源用DontDestroyOnLoad保住Main 场景负责实际跑酷内容每次重开一局就SceneManager.LoadScene重载 Main。这样做的好处是重开一局时所有运行时状态干净地归零不用逐个脚本写 Reset。我一般会把 Boot 场景当成黑匣子里面只有初始化顺序没有任何玩法逻辑。玩法脚本全部放在 Main 场景随场景卸载自动清空。你要排查跑第二局分数没归零这种问题第一个怀疑对象就是某个脚本被挂到了 Boot 场景里或者被DontDestroyOnLoad保活了。2.2 脚本职责表与依赖关系跑酷工程的脚本数量看着多实际职责就那么几类把这张表对照着看找入口会快很多脚本职责谁调用它GameManager状态机Idle/Running/Dead、分数、重开各模块事件PlayerController切轨、跳跃、下滑的输入响应与位移输入层InputRouter键盘、触屏、手柄统一成三个动作每帧TrackSpawner决定下一段拼哪个、拼在哪、什么时候回收GameManagerSegmentPool段的入池出池TrackSpawnerObstacleSpawner段内障碍与金币的摆放段激活时DifficultyCurve按已跑距离给出生成密度和速度倍率TrackSpawnerPickupHandler金币、道具的触发判定Unity 物理回调依赖方向要单向GameManager 不知道 PlayerController 的内部实现只监听它抛的OnPlayerDied事件TrackSpawner 不知道障碍的具体种类只从段预制体上挂的SegmentContent组件里读配置。这种上层只发指令、下层只报事件的分法是这套源码能改得动的前提。反过来如果某个工程里 PlayerController 直接持有 TrackSpawner 的引用、又反过来读玩家的位置改一个地方就得连带改三处这就是典型的耦合翻车。2.3 最短跑通路径三次设置加一次编译拿到工程后别急着点 Play。按这个顺序走能避开 90% 的打开就报错第一步确认 Unity 版本。工程根目录的ProjectSettings/ProjectVersion.txt里写着版本号用同大版本打开跨大版本升级会触发 API 重命名和 Prefab 结构变化报一堆红字。没有对应版本就用 Unity Hub 装一个同大版本的比升级工程省事。第二步检查 Package 依赖。打开Packages/manifest.json看有没有走网络的包比如某些后处理、某些 UI 扩展。如果有先把网络和本地缓存处理好不然打开工程会卡在解析包依赖那一步进度条走一半停住。# 查看工程使用的 Unity 版本决定用哪个编辑器打开 cat ProjectSettings/ProjectVersion.txt # 列出 manifest 里声明的依赖快速识别哪些需要联网拉取 cat Packages/manifest.json这两条命令的作用是在打开之前先把版本和依赖看明白。ProjectVersion.txt里只有m_EditorVersion一行有用其他忽略manifest.json关心的是dependencies节点下的包名凡是带com.unity.前缀的多数能从缓存拿到第三方包名需要单独确认。第三步打开 Main 场景看 Hierarchy 里有没有 Missing Script。有的话通常是脚本编译失败导致引用断开先看 Console 第一条报错把编译过了再谈运行。编译通过后点 Play角色应该自动开始向前跑按方向键切轨、空格跳。提示如果 Play 之后角色原地不动先看 TrackSpawner 上的player字段有没有拖引用再看 GameManager 的初始状态是不是 Idle 没被切到 Running。这两处是新手最常见的跑不起来原因。2.4 关键参数面板数值改了会怎样跑酷的手感全靠几个浮点数撑着这些参数一般在 PlayerController 和 TrackSpawner 的 Inspector 上暴露。改之前得知道每个数管什么参数典型值调大的后果调小的后果laneWidth2.4赛道变宽切轨位移大容易跑出屏幕轨道挤在一起视觉上分不清laneSwitchSpeed14切轨变瞬移失去缓冲感切轨拖沓高速下反应不过来baseSpeed12初速快新手一上来就撞初速慢前三秒没紧张感speedGrowth0.35/百米后期速度爆炸容错为零跑十分钟还是那个速度无聊jumpHeight2.2跳太高越过障碍后落地慢跳不过高障碍直接撞gravity-42下落快跳跃像贴地弹滞空久节奏失控我一般先调baseSpeed和speedGrowth这两个因为它们决定了整局的节奏曲线其他参数都是在这个节奏上做微调。有个血泪经验jumpHeight和gravity必须一起改只改高度不改重力跳跃的滞空时间会变得很奇怪玩家会觉得跳起来了但落不下来这在测试阶段反馈里出现的频率极高。3. 角色控制与无限赛道跑酷手感到底由哪几行代码决定跑酷游戏的手感这个词听着玄学拆开看其实就三件事切轨有没有缓冲、跳跃滞空多久、速度增长是否可感知。这三件事在代码里对应三个非常具体的实现位置找对了地方改起来是分钟级的。3.1 三轨道输入抽象键盘、滑屏走同一个入口输入层最容易写歪的地方是把键盘和触屏分别写一遍逻辑最后两份代码行为不一致。正确做法是先抽象出三个动作左切、右切、跳下滑算第四个再由不同的输入源去填充这三个动作。using UnityEngine; // 输入抽象层只负责把各种输入源翻译成三个离散动作 public class InputRouter : MonoBehaviour { public bool SwipeLeft { get; private set; } public bool SwipeRight { get; private set; } public bool JumpPressed{ get; private set; } private Vector2 touchStart; private const float SwipeThreshold 60f; // 像素低于此值视为点击 void Update() { SwipeLeft SwipeRight JumpPressed false; // 键盘A/D 或左右方向键空格跳 if (Input.GetKeyDown(KeyCode.A) || Input.GetKeyDown(KeyCode.LeftArrow)) SwipeLeft true; if (Input.GetKeyDown(KeyCode.D) || Input.GetKeyDown(KeyCode.RightArrow)) SwipeRight true; if (Input.GetKeyDown(KeyCode.Space)) JumpPressed true; // 触屏按下记起点抬起算位移方向 if (Input.touchCount 0) { Touch t Input.GetTouch(0); if (t.phase TouchPhase.Began) touchStart t.position; else if (t.phase TouchPhase.Ended) { Vector2 delta t.position - touchStart; if (delta.magnitude SwipeThreshold) return; // 视为点击不处理 if (Mathf.Abs(delta.x) Mathf.Abs(delta.y)) { if (delta.x 0) SwipeRight true; else SwipeLeft true; } else if (delta.y 0) JumpPressed true; } } } }这段的意义在于把输入和响应彻底切开。SwipeThreshold这个 60 像素的阈值不是随手写的它决定了一次滑动要多长才算数调大到 120玩家会频繁觉得我明明滑了但没反应调小到 20手指轻微抖动就会误触发切轨。移动端分辨率差异大稳妥做法是把它改成Screen.dpi * 0.2f之类跟屏幕密度挂钩的值。PlayerController 只读这三个 bool不做任何输入判断所以之后接手柄、接键盘重映射都只改 InputRouter 一个文件。3.2 跳跃与重力为什么不能用刚体默认值跑酷角色用 CharacterController 比 Rigidbody 多原因是 Rigidbody 的物理响应太真会把跑酷需要的干净手感搅乱。用 CharacterController 时重力得自己算using UnityEngine; [RequireComponent(typeof(CharacterController))] public class PlayerController : MonoBehaviour { [Header(轨道)] public float laneWidth 2.4f; public float laneSwitchSpeed 14f; public int laneCount 3; [Header(跳跃)] public float jumpHeight 2.2f; public float gravity -42f; [Header(场景引用)] public InputRouter input; private CharacterController cc; private int targetLane; // 0 左 / 1 中 / 2 右 private float verticalVelocity; // 当前竖直速度 private float forwardSpeed; // 由 GameManager 每帧下发 void Awake() { cc GetComponentCharacterController(); targetLane laneCount / 2; // 默认站中间 } void Update() { HandleLaneInput(); HandleJumpAndGravity(); ApplyMotion(); } // 输入 - 目标轨道索引越界时夹紧 private void HandleLaneInput() { if (input.SwipeLeft) targetLane Mathf.Max(0, targetLane - 1); if (input.SwipeRight) targetLane Mathf.Min(laneCount - 1, targetLane 1); } private void HandleJumpAndGravity() { // 落地时把竖直速度清成一个小的负值保证下一帧仍判定为 grounded if (cc.isGrounded verticalVelocity 0f) verticalVelocity -2f; if (cc.isGrounded input.JumpPressed) { // 由目标高度反推初速度v sqrt(2 * g * h) verticalVelocity Mathf.Sqrt(jumpHeight * -2f * gravity); } verticalVelocity gravity * Time.deltaTime; } private void ApplyMotion() { // 水平方向朝目标轨道的 X 坐标做 MoveTowards天然带缓冲 float targetX (targetLane - (laneCount - 1) * 0.5f) * laneWidth; Vector3 pos transform.position; pos.x Mathf.MoveTowards(pos.x, targetX, laneSwitchSpeed * Time.deltaTime); transform.position pos; // 竖直 前进交给 CharacterController 统一位移避免穿墙 Vector3 motion new Vector3(0f, verticalVelocity, forwardSpeed) * Time.deltaTime; cc.Move(motion); } public void SetForwardSpeed(float speed) forwardSpeed speed; }几个参数值得单独说。verticalVelocity -2f这个写法是 CharacterController 的老规矩落地时不给一点向下的速度isGrounded会在两帧之间反复横跳跳跃就会偶发失效这是跑酷项目里排第一的玄学 bug。Mathf.Sqrt(jumpHeight * -2f * gravity)用的是从高度反推初速的公式好处是你只调jumpHeight就能控制跳多高重力常量独立存在换手感时不用两个数一起猜。水平方向的Mathf.MoveTowards是切轨带缓冲的关键。如果直接pos.x targetX切轨就是瞬移玩家没有任何过渡感知撞到旁边的障碍会认为是游戏判定有问题。laneSwitchSpeed决定这个过渡有多快14 在 2.4 米轨道间距下大约是 0.17 秒完成一次切轨手感偏紧适合高速跑酷想做得轻一点降到 8 到 10。3.3 赛道分段拼接用整数索引代替浮点累加无限赛道最常见也最隐蔽的坑是用浮点累加算下一段的位置// 错误示范每次 segmentLength跑久了必然出现接缝 nextSpawnZ segmentLength;float 的精度在几千米的量级上就开始不够用了段与段之间会出现零点几毫米的缝玩到后期地面看着像开裂角色踩上去偶尔抖一下。正确做法是用整数段号乘段长using System.Collections.Generic; using UnityEngine; // 赛道分段生成以段号 × 段长计算位置杜绝浮点累积误差 public class TrackSpawner : MonoBehaviour { public Transform player; public SegmentPool pool; public float segmentLength 30f; public int visibleSegments 5; // 前方保留几段 public int recycleBehind 2; // 身后几段回收 private int headIndex; // 队首段号前方最新 private int tailIndex; // 队尾段号身后最旧 private readonly ListGameObject active new ListGameObject(); void Start() { // 开局先铺满可见窗口 for (int i 0; i visibleSegments; i) SpawnNext(); } void Update() { // 玩家跑过当前队尾段的中点就回收队尾、补一段队首 float tailStartZ tailIndex * segmentLength; if (player.position.z - tailStartZ segmentLength * (1 recycleBehind) * 0f segmentLength) RecycleTail(); // 前方空白就补段 while (headIndex * segmentLength player.position.z segmentLength * visibleSegments) SpawnNext(); } private void SpawnNext() { GameObject seg pool.Get(); // 关键位置由整数段号乘段长得到不做任何累加 seg.transform.position new Vector3(0f, 0f, headIndex * segmentLength); seg.SetActive(true); active.Add(seg); headIndex; } private void RecycleTail() { GameObject seg active[0]; active.RemoveAt(0); seg.SetActive(false); pool.Return(seg); tailIndex; } }headIndex * segmentLength这行是整个无限赛道的稳定性基石。段号是 int段长是 float乘积在几万米范围内误差都还在可接受区间不会像累加那样越跑越歪。visibleSegments控制前方保留几段太小会导致玩家看到赛道尽头露出天空太大会让同屏段数变多、开销上升5 到 7 是比较稳的区间。recycleBehind表示身后留几段不立刻回收留一点是为了让玩家回头看时不至于看到空白。这个值不用大2 段足够。3.4 分段回收与预生成的距离窗口上面那段Update里的回收判断写得比较粗实际工程里更稳的写法是判断玩家的 Z 坐标是否已经越过队尾段的末尾// 玩家越过队尾段末尾就直接回收不再等下一个窗口 float tailEndZ (tailIndex 1) * segmentLength; if (player.position.z - tailEndZ segmentLength * recycleBehind) RecycleTail();这段的意思是身后的余量超过 recycleBehind 段就回收。判断条件是减法而不是绝对值玩家在赛道上的 Z 一直是正的越跑越大减法不会溢出。预生成的时机也很讲究。如果在玩家跑到段末尾才生成下一段会出现一帧的空白高速下肉眼可见闪烁。稳妥做法是让生成判断始终领先玩家visibleSegments * segmentLength的距离也就是while那个循环干的事。这个 while 每帧最多跑一两次不会成为性能热点但它保证了玩家永远看不到赛道尽头。4. 障碍与金币的生成策略权重表、对象池与难度曲线无限赛道跑通之后第二个要解决的问题是内容从哪来。跑酷的乐趣来自节奏变化而节奏变化靠的是障碍密度、障碍类型、金币路径三者的组合。这三样如果写死玩三局就腻如果随机得太纯会出现连续五个高障碍把路堵死的情况。4.1 对象池赛道上一切可复现的东西都不该 Instantiate跑酷工程里 Instantiate 和 Destroy 是最容易被滥用的两个 API。每段赛道生成几十个金币、几个障碍一分钟内就是几百次实例化和销毁GC 一触发就是明显的掉帧。对象池是必须的using System.Collections.Generic; using UnityEngine; // 通用对象池按预制体分桶出池时重置 Transform入池时挂到池节点下 public class SegmentPool : MonoBehaviour { [System.Serializable] public class PoolBucket { public GameObject prefab; public int prewarm 10; // 预热数量 [HideInInspector] public QueueGameObject idle new QueueGameObject(); } public ListPoolBucket buckets; void Awake() { foreach (var b in buckets) { for (int i 0; i b.prewarm; i) { GameObject go Instantiate(b.prefab, transform); go.SetActive(false); b.idle.Enqueue(go); } } } public GameObject Get(GameObject prefab) { var bucket buckets.Find(b b.prefab prefab); if (bucket null) return Instantiate(prefab); // 没配置的走兜底 if (bucket.idle.Count 0) { // 池空了就扩容一个避免运行时卡顿 GameObject extra Instantiate(prefab, transform); extra.SetActive(false); bucket.idle.Enqueue(extra); } GameObject go bucket.idle.Dequeue(); go.transform.SetParent(null); // 出池脱离池节点方便摆位置 return go; } public void Return(GameObject prefab, GameObject go) { var bucket buckets.Find(b b.prefab prefab); if (bucket null) { Destroy(go); return; } go.SetActive(false); go.transform.SetParent(transform); // 回池统一挂回去保持 Hierarchy 干净 go.transform.localPosition Vector3.zero; bucket.idle.Enqueue(go); } }prewarm这个预热数量决定了开局那一下会不会卡。赛道上同屏最多出现多少同类物件prewarm 就配多少宁可多配几个也不要运行时扩容。Get里的扩容分支是保底手段不是正常路径如果你发现游戏跑起来池子一直在扩容说明 prewarm 配小了或者回收逻辑有漏洞导致对象没回池。Return里把对象挂回池节点并重置localPosition这两步容易被省省了之后 Hierarchy 里会堆几百个散落在世界坐标各处的对象调试时根本找不到东西而且下次出池时如果忘了设位置对象会从上次的位置冒出来。4.2 权重表驱动的生成器障碍生成最忌讳Random.Range(0, obstacleTypes.Length)这种等概率写法高难度障碍和低难度障碍出现频率一样难度曲线就完全靠速度撑很单调。用权重表using System; using UnityEngine; // 权重表按当前难度选择合适的障碍类型 [Serializable] public class WeightedObstacle { public GameObject prefab; public float weight; // 相对权重不是百分比 public int minMeters; // 多少米之后才开始出现 } public class ObstacleSpawner : MonoBehaviour { public WeightedObstacle[] obstacles; // 按已跑距离筛掉尚不该出现的类型再按权重抽一个 public GameObject Pick(float meters, float difficulty01) { float total 0f; foreach (var o in obstacles) { if (meters o.minMeters) continue; // 简单做法类型越硬随难度提升权重越大 total o.weight * (1f difficulty01); } float r UnityEngine.Random.value * total; foreach (var o in obstacles) { if (meters o.minMeters) continue; r - o.weight * (1f difficulty01); if (r 0f) return o.prefab; } return obstacles[0].prefab; } }minMeters这个字段是节流阀。前 200 米只让低障碍出现玩家有时间熟悉操作过了 500 米再引入需要跳切轨组合的复合障碍。weight是相对值写 1 和写 10 只是比例关系不用凑成 100。difficulty01由难度曲线给0 到 1 之间。上面用weight * (1 difficulty01)这个形式比较简单粗暴但有效难度越高所有类型的权重一起涨但涨的倍率相同实际效果是总密度上升。如果想做成高难度类型占比上升就把系数改成跟类型挂钩的字段。4.3 难度曲线与安全通道难度曲线我一般用一个 AnimationCurve 在 Inspector 里可视化调按已跑距离映射到 0 到 1public class DifficultyCurve : MonoBehaviour { public AnimationCurve curve; // X: 0..1 归一化距离, Y: 0..1 难度 public float fullDifficultyMeters 1500f; // 跑到这个距离达到满难度 public float Evaluate(float meters) { float t Mathf.Clamp01(meters / fullDifficultyMeters); return curve.Evaluate(t); } }fullDifficultyMeters这个值决定了游戏多久之后开始不讲道理。设 1500 米节奏是慢热型设 500 米前三分钟就逼到极限。这个数没有标准答案取决于你想让一局跑多久。多数跑酷项目的单局时长控制在 2 到 4 分钟往这个方向反推就行。安全通道是另一个必须实现的东西。随机生成障碍时至少要保证三条轨道里有一条是空的否则会出现三条道全是墙的死局// 生成一批障碍后校验如果三条轨道都被占随机清空一条 bool[] occupied new bool[laneCount]; // ... 摆放逻辑填充 occupied if (Array.TrueForAll(occupied, o o)) { int safe UnityEngine.Random.Range(0, laneCount); // 清掉第 safe 轨道上的障碍保证玩家永远有路可走 }这个校验必须在障碍摆放完之后执行不能在摆放过程中做因为摆放过程是逐条轨道处理的中途判断的时候还不知道后面两条会放什么。4.4 金币与道具的触发判定金币用 Trigger 碰撞体不用实体碰撞避免影响角色的物理移动。判定脚本挂在金币上靠标签区分类型using UnityEngine; public class PickupHandler : MonoBehaviour { public int scoreValue 10; public AudioClip pickupSfx; void OnTriggerEnter(Collider other) { // 只认玩家标签避免赛道段或其它触发器误判 if (!other.CompareTag(Player)) return; ScoreManager.Instance.Add(scoreValue); AudioSource.PlayClipAtPoint(pickupSfx, transform.position); // 直接回池不要 Destroy PickupPool.Instance.Return(gameObject); } }CompareTag比other.tag Player快而且标签拼错时 Unity 会直接报错提示不会静默返回 false。PlayClipAtPoint会在场景里临时创建一个 AudioSource 然后销毁高频拾取时会有一点开销工程里如果金币特别密改成用一个常驻的 AudioSource 播PlayOneShot更稳。这里最容易翻车的是碰撞层设置。Player 和 Pickup 必须至少有一方带 Rigidbody否则 Trigger 不触发CharacterController 本身在 Trigger 判定里表现和 Collider 类似但两边都要在 Physics 矩阵里勾选可碰撞。这两点后面避坑章节还会展开。5. 跑酷工程避坑排查五个翻车现场与它们的解法这套源码能跑起来不算难难的是跑起来之后那些看着像玄学的问题。下面五条是我在不同跑酷项目里反复遇到的基本覆盖了从打开工程到上线前的典型故障。5.1 现象角色直接穿过障碍物碰撞回调完全不触发原因通常有两个方向。一是层Layer没配好Player 和 Obstacle 所在的层在 Physics 矩阵里被取消勾选了物理引擎压根不做这两个层之间的碰撞检测。二是 Rigidbody 的Collision Detection停留在 Discrete角色速度拉到 20 米/秒以上时一帧位移超过障碍物的厚度物理引擎在两帧之间跳过了障碍检测不到。解决方式分两步。先把 Physics 矩阵里 Player 与 Obstacle 的交叉项勾上这一步能解决 70% 的情况。剩下 30% 是高速穿透把障碍物改成 Trigger 加脚本内做距离判定或者给角色挂一个前向的射线预判在cc.Move之前先Physics.SphereCast探一下前方 0.5 米命中障碍就直接判定死亡。cc.Move本身对静态碰撞体是可靠的问题出在障碍物是动态生成、有时还在移动的情况下预判比事后检测稳。5.2 现象跑到两三千米后赛道出现细缝角色经过时轻微抖动这是浮点精度问题前面 3.3 提过但值得再强调一次因为它的表现太有迷惑性——前期完全正常跑到一定距离才开始出现很容易被误判成美术资源拼缝没对齐或者某个段预制体的 pivot 偏了。排查方法很直接在 TrackSpawner 里把每个段的实际 Z 坐标打出来看相邻两段的差值是不是严格等于segmentLength。如果差值有尾数就是累加导致的。解决就是把nextSpawnZ segmentLength改成index * segmentLength索引用 int。改完之后跑一万米都不会有缝。顺带一提段的 pivot 也要统一。如果有的段 pivot 在中心、有的在左端即使位置算得再准视觉上还是会错位。工程规范里应该写死所有赛道段的 pivot 在段的前端中点。5.3 现象帧率从 60 掉到 30 以下Profiler 里 GC Alloc 每帧都在涨GC 压力来源通常有三处一是生成物件时没走池、直接 Instantiate二是每帧用new Vector3、字符串拼接之类的小对象分配三是 UI 文本每帧刷新分数。前两个是主因。解决顺序应该是先看 Profiler 的 GC Alloc 排序找分配量最大的那一行。跑酷项目里最常见的是金币和障碍在生成时 Instantiate改走对象池之后 GC 立刻降下来。其次是分数 UIText 组件每帧赋值会触发网格重建改成只在分数变化时更新或者用 TextMeshPro 的SetText带缓存。第三是物理查询Physics.OverlapSphere每帧调用会产生数组分配改成非分配版本Physics.OverlapSphereNonAlloc并复用一个静态数组。5.4 现象切轨时角色有半帧的抖动偶尔还会卡在两条轨道中间原因基本是直接改transform.position和物理系统打架。如果角色身上还挂着 Rigidbody直接改 transform 会让物理引擎的插值和你的赋值相互覆盖表现出来就是抖。如果只有 CharacterController抖动通常来自切轨用的是Lerp而不是MoveTowards——Lerp每帧逼近但不收敛配合帧率波动会产生视觉上的细微抖动。解决是把切轨改成Mathf.MoveTowards(pos.x, targetX, speed * Time.deltaTime)的形式它在到达目标后严格等于目标值不存在无限逼近。另外涉及物理移动的部分统一走cc.Move不要混用 transform 赋值和 Move两者的坐标系和碰撞处理方式不一样混用就会出现角色卡在半路。5.5 现象打包到移动端后手感跟编辑器里完全不一样这是帧率差异引起的。编辑器里跑 120 帧移动端跑 60 帧甚至 30 帧所有用Time.deltaTime的地方理论上应该自适应但实际会出现两个问题一是用Input.GetKeyDown这类帧事件逻辑在低帧率下会漏输入二是Update里的跳跃判定如果依赖isGrounded的瞬时值在低帧率下会错过落地帧。解决方法是把所有输入判定改成事件攒着、下一帧统一消费也就是 InputRouter 里用 bool 标记、Update 末尾清零这样一帧内多长的输入都不会丢。跳跃判定则在HandleJumpAndGravity里先处理isGrounded的落地重置再处理起跳顺序不能反。另外在 Quality Settings 里把VSync关掉、Target Frame Rate设成 60让编辑器和真机的帧率基准一致调试时的手感才对得上。注意这几条里 5.1 和 5.4 经常同时出现表现出来都是碰撞不灵但根因一个在层配置、一个在移动方式。排查时先看 Physics 矩阵再看移动代码顺序别反反了会白改半天。6. 二次开发换皮、加角色、接数据的改造顺序拿到这套源码之后二次开发最容易犯的错是从美术资源开始换。换完模型发现动画状态机的参数名对不上改完动画发现角色控制器里写死了胶囊体的尺寸改完尺寸发现赛道段的宽度是按旧角色算的一路改下去越改越乱。合理的顺序是先定数据、再定逻辑、最后定表现。改造点大致可以按这个优先级排改造目标改动位置预估工作量风险换角色模型与动画Player 预制体、Animator小动画状态名、根运动换赛道皮肤段预制体的材质与装饰物小碰撞体不要跟着换加新障碍类型WeightedObstacle 表 预制体中层与安全通道校验加新角色多角色可选角色配置 ScriptableObject中参数分散在各脚本接排行榜与存档Core 层新增服务大生命周期与重开清理加多角色这个需求特别值得单独说因为它是把散落在 Inspector 上的参数收敛成数据资产的最好契机。做法是定义一个 ScriptableObjectusing UnityEngine; // 角色配置把原本散落在 PlayerController 上的手感参数收进来 [CreateAssetMenu(menuName Runner/Character Config)] public class CharacterConfig : ScriptableObject { public string displayName; public GameObject modelPrefab; public float laneSwitchSpeed 14f; public float jumpHeight 2.2f; public float gravity -42f; public float baseSpeed 12f; }定义完之后PlayerController 不再自己在 Inspector 上存这些数而是在Awake里从配置资产读。这一步改完之后加一个新角色只需要新建一个资产、填几个数、换一个模型预制体不用碰任何代码。之后想做角色解锁、角色属性差异、皮肤商店都是在这个资产列表上做文章。验证方式我一般这么走改完参数先不跑完整局在 PlayerController 上挂一个临时调试键按一下直接把forwardSpeed设成 30看看高速下切轨和跳跃有没有穿透再按一下把Time.timeScale设成 0.2用慢动作看切轨的插值曲线是不是平滑收敛。这两个极端情况都过了正常速度下的手感基本不会有问题。接排行榜和存档这类需求改动点在 Core 层原则是新增服务不改原有模块。分数变化通过事件抛出来排行榜服务订阅这个事件自己决定什么时候上报。这样即使排行榜接不上游戏本体也不受影响不会出现网络一断游戏就卡死的情况。从那以后我每次接手一份跑酷源码都强制走一遍先跑通、再打印赛道坐标、最后压测 GC这三步哪怕工程看着再简单也不跳。这三步花不了二十分钟但能提前把后面几天的调试时间省出来。希望帮到你。本文还有配套的精品资源点击获取
