企业官网建设流程全解析

简介：Unity跑酷小游戏源工程是一份可直接运行的完整Unity项目，面向想要入门或进阶Unity开发的游戏爱好者与初学者，用于学习跑酷玩法从场景搭建到逻辑控制的完整实现路径。工程包共2000个文件，大小约22.39MB，核心内容集中在Assets目录，涵盖215个C#脚本、29个Prefab预制体、40个Asset资源、29个FBX模型、30张PNG及29个PSD美术文件、13个材质文件等，同时包含ProjectSettings项目设置、Packages包管理与Library等Unity工程目录结构，便于对照学习Unity项目的组织方式，压缩包为zip格式。目前已有6432人学习下载。通过分析源工程，可以重点研究角色控制器的设计、碰撞检测与响应、关卡循环生成、动画状态机切换以及C#脚本驱动的游戏逻辑，还能借助ProjectSettings中的图形、输入、物理参数了解不同设备下的性能优化思路，并通过脚本与预制体对照掌握跑酷游戏的核心实现。对于希望快速上手跑酷游戏开发、或需要完整工程参考来复现同类玩法的学习者，是一份很有价值的实战素材。

1. 从别人工程里学跑酷，比自己从零写快得多

很多开发者拿到一份 Unity 跑酷小游戏源工程，第一反应是打开场景直接点 Play，跑两步觉得手感不对，就开始改参数，改完发现跳不过去、撞墙没反应、金币不计数，最后得出“这份工程有问题”的结论。实际上，跑酷类游戏看似简单，核心却在「速度曲线 + 判定模型 + 状态机」这三件事的配合上。源工程的价值不在于能跑，而在于它把这三件事的默认值、连法、坑位都摆在了你面前。这篇笔记会带你从项目结构入手，拆出跑酷游戏真正值得抄的那几块，再把参数调校和常见翻车点逐个过一遍。适合两类人：一类是刚学 Unity 想拿小项目练手的人，一类是准备做商业跑酷、但不想在基础手感上浪费两周的人。

2. 工程里到底该看哪几个文件：跑酷源项目的骨架拆解

一份标准的 Unity 跑酷小游戏源工程，拿到手先别急着开场景。先看 Assets 目录结构，搞清楚哪些是核心脚本、哪些是美术资源、哪些是第三方插件。跑酷游戏的逻辑高度集中，通常不需要像 RPG 那样铺几百个脚本，核心往往就三五个类。

2.1 场景层级与对象划分：地面、玩家、生成器各司其职

打开 Main.unity 场景后，Hierarchy 面板里一般会看到这样的骨架：一个 GameManager 空物体管理全局状态，一个 Player 物体带着角色模型和碰撞体，一个 Ground 或 Track 物体负责地面片段，还有 Spawner、ObstaclePool、CoinManager 这类生成和管理类物体。理解场景层级，最重要的是看每个物体的脚本挂载关系，以及它们之间是通过 Inspector 拖引用还是通过代码查找。拖引用适合小项目，查找方式更适合动态生成。

跑酷游戏的地面几乎不会是一整条长跑道，而是多段重复拼接的。源工程里通常会有一个 GroundSegment 预制体，里面有地面模型、障碍物生成点、金币摆放点。GameManager 或 TrackSpawner 负责在 Player 前进时，按需把新的 GroundSegment 实例化到前方，同时销毁或回收后方的旧片段。这个「生成-回收」机制决定了游戏的可持续性——做无限跑酷还是有限关卡，区别就在这里。

玩家控制方面，常见做法是三车道跑酷（左、中、右），或者单跑道跳跃加滑铲。预览工程时注意看 Player 身上挂的是 CharacterController 还是 Rigidbody，这决定了手感调校的方向。CharacterController 适合做纯逻辑位移，Rigidbody 适合做物理互动。跑酷游戏通常用 CharacterController 加自定义重力，因为这样对跳跃高度的控制最直接，不会因为物理引擎的默认摩擦和弹力导致手感飘。

// 核心玩家控制脚本的常见骨架（伪代码示范结构） public class PlayerController : MonoBehaviour { public float forwardSpeed = 10f; // 前进速度，跑酷手感的第一要素 public float jumpForce = 8f; // 跳跃力度，影响起跳高度和滞空时长 public float gravity = -20f; // 自定义重力，比物理引擎默认值更可控 public float laneSwitchSpeed = 15f; // 左右换道速度 private int currentLane = 1; // 0=左，1=中，2=右 private Vector3 targetPosition; void Update() { // 前进：用 Translate 直接推，不用物理力，保证速度恒定 transform.Translate(Vector3.forward * forwardSpeed * Time.deltaTime); // 换道：按方向键改目标位置，用 MoveTowards 平滑过渡 if (Input.GetKeyDown(KeyCode.A) && currentLane > 0) { currentLane--; targetPosition = new Vector3(GetLaneX(currentLane), transform.position.y, transform.position.z); } // 跳跃：只在 grounded 状态允许起跳 if (Input.GetKeyDown(KeyCode.Space) && isGrounded) { verticalVelocity = jumpForce; isGrounded = false; } // 垂直方向用自定义重力积分，落地时归零 verticalVelocity += gravity * Time.deltaTime; transform.position += new Vector3(0, verticalVelocity, 0) * Time.deltaTime; } float GetLaneX(int lane) { // 三车道中心线，偏移量取决于项目里跑道宽度的设计 return (lane - 1) * 2f; } }

这段代码展示了跑酷玩家控制的典型结构。forwardSpeed 不是放在 Start 里初始化，而是 public 字段，方便在 Inspector 里直接调。新手最容易忽略的一点：换道和跳跃不要在 FixedUpdate 里做，因为输入检测是每帧走的，物理更新频率更低，会导致操作延迟感。另外，这里用 isGrounded 布尔值做状态判断，它的赋值来源通常是脚底射线检测或碰撞回调，源工程里如果写的是 OnCollisionStay，需要注意碰撞体的大小和位置是否合理。

2.2 预制体与对象池：为什么无限跑酷不卡

跑酷游戏里最影响性能的操作是不断 Instantiate 和 Destroy。一份工程跑得流畅与否，关键看它用没用对象池。对象池的意思是预先创建一批障碍物、金币、地面片段，藏在一个空物体下，需要时激活，不需要时隐藏，而不是销毁重造。

// 对象池的简化实现，跑酷源工程里几乎必备 public class ObstaclePool : MonoBehaviour { public GameObject obstaclePrefab; public int poolSize = 20; private List<GameObject> pool = new List<GameObject>(); void Start() { // 预创建 20 个障碍物，全部隐藏 for (int i = 0; i < poolSize; i++) { GameObject obj = Instantiate(obstaclePrefab); obj.SetActive(false); pool.Add(obj); } } public GameObject GetObstacle() { // 找一个未激活的障碍物返回 foreach (GameObject obj in pool) { if (!obj.activeInHierarchy) { obj.SetActive(true); return obj; } } return null; // 池满了，可以不创建或扩容 } public void ReturnObstacle(GameObject obj) { // 回收：传给地面片段管理，移到场景外或直接隐藏 obj.SetActive(false); } }

对象池的池大小不是越大越好。跑酷游戏的障碍物同时活跃数量受屏幕可视范围和生成距离限制，一般 10 到 30 就够。池子太大会增加内存占用，太小会导致生成时拿不到对象。判断池大小是否合理的方法：看 Game 视图中同时可见的障碍物数量上限，再加 20% 余量。源工程里如果用了对象池但依然卡顿，问题多半出在生成距离设置太远，或者地面片段里挂载了过多未回收的粒子特效。

3. 把源工程跑起来：导入、版本对齐与第一次 Play 前的检查

拿到源工程压缩包，第一件事不是解压双击，而是确认 Unity 版本。Unity 的工程版本兼容性是个大坑，2020 LTS 和 2021 LTS 之间的 API 差异已经不小，更别说升到 Unity 6 后有些老旧写法直接编译报错。

3.1 Unity 版本与渲染管线对齐：最常见的打开即报错场景

打开工程前先看 ProjectSettings/ProjectVersion.txt 里记录的版本号，例如 m_EditorVersion: 2021.3.38f1c1。如果你的本机 Unity 版本和它差一个小版本，通常可以直接打开让 Unity 自动升级。如果差一个大版本，比如工程是 2019 写的、本机是 2022，大概率会遇到两类问题：一是旧版 Asset Store 的第三方插件路径失效，二是 Shader 或渲染管线不兼容导致的材质变紫。

解决思路有三个：优先找同一大版本的最新 patch 包安装；其次尝试用 Unity Hub 添加工程时勾选“升级到当前版本”，看报错内容再定；最不推荐的是直接改 ProjectVersion.txt 里的版本号假装对齐，这只会让报错变得不可预测。打开后第一件事是看 Console 窗口有没有红色报错，如果有，优先处理脚本编译错误，材质和预制体的问题可以先放一边，因为编译不过时场景根本加载不全。

// ProjectVersion.txt 内容检查示例 m_EditorVersion: 2021.3.38f1c1 m_EditorVersionWithRevision: 2021.3.38f1c1 (3a3e1c0f9e1a)

版本对齐后，再检查渲染管线。跑酷游戏的源工程大概率用的是内置渲染管线（Built-in Render Pipeline），因为这类项目通常不是特效导向的，内置管线通用性最好。如果工程里发现管线配置文件或 Shader 引用了 URP（Universal Render Pipeline），就得用 Package Manager 安装 URP 包并迁移材质。迁移材质时最容易踩的坑是：跑酷地面的自发光材质、障碍物的透明度材质在 URP 下表现完全不一样，需要逐个检查。

3.2 首次 Play 前的三分钟排查清单

不管工程能不能编译，在点 Play 之前，建议花三分钟按下面的顺序过一遍：

第一，确认 Main Camera 是否跟随 Player。选中 Main Camera，看有没有挂 FollowPlayer 之类的脚本，且脚本里的 target 变量是否拖了 Player 物体。相机不跟随是跑酷工程最常见的“假死”现象——角色在跑，画面不动，看起来像是卡住了。第二，确认 GameManager 的 Start 方法里是否初始化了玩家速度、金币计数、UI 引用。很多工程把初始状态摆在 Awake 里，如果脚本执行顺序不对，UI 上显示的金币数可能全是 0。第三，确认生成器的起始位置是否在 Player 前方。如果生成器判断距离的逻辑写成了 Vector3.Distance，会导致物体一生成就判定已过玩家，直接触发销毁或回收，表现就是场景里什么都没有。

// 生成距离判断的常见写法 <-> 有问题与没问题的差异 // 常见写法1：基于Z轴差值，只适用于直线跑道 if (player.position.z - lastSpawnZ > spawnInterval) { SpawnNextSegment(); lastSpawnZ = player.position.z; } // 常见写法2：基于距离，弯道场景会误触发 if (Vector3.Distance(player.position, lastSpawnPosition) > spawnInterval) { SpawnNextSegment(); }

直线跑酷用 Z 轴差值最可靠，因为 Vector3.Distance 在玩家频繁换道或跑道有轻微偏移时，会在前后方向未达到阈值时提前触发生成，导致前方物体堆积过密。如果源工程用了写法 2，建议改成写法 1。另一个检查点是导航网格或碰撞矩阵：打开 Edit > Project Settings > Physics，看 Player 所在的 Layer 和 Obstacle 是否在碰撞矩阵中勾选。很多工程把玩家放在 Player 层、障碍物放在 Obstacle 层，但矩阵里漏勾了，导致穿模，这是典型的“看着没问题、跑起来一头雾水”的翻车现场。

4. 手感调校实战：速度、跳跃、判定三个维度的参数与坑

跑酷游戏好不好玩，项目里 80% 的体验集中在“手感”两个字上。而手感不是一个参数，是速度、跳跃、判定三者互相咬合后的结果。如果你只是把源工程里的数值随便改几个，很容易越调越怪。

4.1 速度曲线怎么设：前进速度不是定值，而是一条 Slope

很多新手以为跑酷就是匀速前进，实际做商业项目的都明白，前进速度要随时间是渐增的，否则玩家在 3 分钟后会感觉单调。源工程里大概率有一个 SpeedManager 或者 GameManager 里存储当前速度，然后在 Update 里逐步增加。常见做法是给一个起始速度、一个最大速度和一个加速度，或者直接用一个 AnimationCurve 定义速度曲线。

用系数递增的方式最直观：currentSpeed = Mathf.Min(startSpeed + acceleration * Time.time, maxSpeed)。但要注意 Time.time 是从游戏开始算的，如果你做了暂停功能、复活功能，Time.time 不会重置，会导致玩家复活后速度突变。正确做法是维护一个 distanceTraveled 或 elapsedTime 变量，在暂停和复活时手动调整。

// 正确的速度增长逻辑：用累计时长而不是全局时间 public class SpeedManager : MonoBehaviour { public float startSpeed = 8f; public float maxSpeed = 20f; public float acceleration = 0.5f; private float currentRunTime = 0f; public float CurrentSpeed { get; private set; } void Update() { currentRunTime += Time.deltaTime; CurrentSpeed = Mathf.Min(startSpeed + acceleration * currentRunTime, maxSpeed); } public void ResetRun() { currentRunTime = 0f; CurrentSpeed = startSpeed; } }

加速度设多少合适？看场景密度。游戏里障碍物的分布间隔如果按当前速度设计，例如速度 12 时每 2 秒一个障碍物，那么加速度过高会导致后半程反应时间不足。我一般习惯的做法是：先定最大速度下玩家的最小反应时间（一般不低于 0.8 秒），然后反推障碍物最小间距，再回头定加速度。源工程里如果障碍物是随机生成的，这个联动关系更得算清楚，否则速度越高越像在玩弹幕游戏。

跳跃的手感则要看两个参数：起跳瞬间的速度和滞空时长。跳跃高度由 jumpForce 值和 gravity 值共同决定，滞空时间和这两个的关系不是线性的。如果 gravity 绝对值太大，角色会像被抽走地板一样瞬间落地；如果太小，角色会飘，像在月球上跑。源工程里 gravity 设置成 -15 到 -25 之间都比较常见，关键是和跳跃高度匹配：起跳速度 8、重力 -20 时，峰值高度是 88/(220) = 1.6 米，滞空时间约为 0.8 秒，这个数值组合对普通障碍物高度是合理的。

4.2 碰撞判定：为什么你觉得“明明躲开了”却死了

跑酷源工程里被吐槽最多的往往是碰撞判定太严或太松。原因是跑酷游戏的碰撞体通常不是完整包裹角色模型，而是用一个胶囊体或盒体作为“受击盒”。受击盒的位置和大小决定了判定是否公平。Unity 的碰撞检测是按物理引擎精确算的，没有玄学，你觉得不合理，要么是碰撞盒尺寸问题，要么是模型动画的位移没有同步到碰撞体。

最典型的案例：人物模型在奔跑时有一个弯腰动作，动画让模型视觉重心前倾，但碰撞体是固定的，导致玩家看到角色头顶明明低于障碍物下沿，还是被撞。反过来，如果碰撞体比模型小一圈，玩家会觉得“这都能躲”，爽感上来了但游戏太简单。源工程调校时，建议把 Player 和 Obstacle 的碰撞体都在 Scene 视图下打开线框显示（按 Shift+V 或通过 Gizmos 开关），逐个对照模型边界和碰撞体边界。

// 碰撞体调试的临时脚本，运行时画出玩家碰撞盒的实际包围框 public class DebugCollider : MonoBehaviour { void OnDrawGizmos() { Collider col = GetComponent<Collider>(); if (col == null) return; Gizmos.color = Color.yellow; Gizmos.DrawWireCube(col.bounds.center, col.bounds.size); } }

把这个脚本临时挂到 Player 和 Obstacle 预制体上，Play 模式下就能在 Scene 视图里看到实际受击范围。常见的问题是：障碍物的碰撞体比视觉模型大了 30% 以上，特别是那些带刺、带尖角的模型，美术做的模型精细，碰撞体却用了一个大盒体包住，玩家躲过了尖角却死在空气里。遇到这种，把碰撞体改成多个小碰撞体组合，或者用 MeshCollider（但要配合 Convex 选项，且注意性能）。

4.3 三车道换道的响应手感：输入延迟和补间函数

三车道跑酷的换道操作，响应速度决定了游戏是“跟手”还是“发飘”。源工程里常见两种实现：一是直接改位置，瞬间到位，响应最跟手但视觉上很生硬；二是用 Lerp 或 MoveTowards 做平滑过渡，过渡时间是手感的关键。过渡太快像瞬移，太慢玩家会觉得指令没被接收。

推荐做法是把过渡时间和速度关联起来：车道宽度固定为 2 米，换道速度 15 意味着 0.13 秒完成换道，这个速度在拇指操作的手机上偏快但尚可接受，在 PC 键盘上则刚好。更重要的是，换道过程中要允许玩家连续操作：如果上一次换道还没结束就按了第二次换道，源工程里如果用了 if (isSwitching) return; 这种锁，手感会非常难受，正确做法是记录目标位置，允许中断当前 Lerp 并立刻向新目标移动。

// 允许中断的换道逻辑：目标位置永远是最新输入 void Update() { if (Input.GetKeyDown(KeyCode.A)) targetLane = Mathf.Max(0, targetLane - 1); if (Input.GetKeyDown(KeyCode.D)) targetLane = Mathf.Min(2, targetLane + 1); float targetX = (targetLane - 1) * laneWidth; // 不判断是否到达，每帧都向目标移动，天然支持中断 float newX = Mathf.MoveTowards(transform.position.x, targetX, laneSwitchSpeed * Time.deltaTime); transform.position = new Vector3(newX, transform.position.y, transform.position.z); }

注意这里的 targetLane 在按键时立即更新，MoveTowards 每帧执行。即使第一次换道未完成，再次按键会更新 targetX，角色立即转向新的目标位置，没有“锁死”的僵硬感。源工程里如果换道补间用的是 Co-routine 且每次启动前先 StopAllCoroutines，表现就是角色会频繁抽搐，因为上一个协程被强制终止，位置从半途开始重新计算——这种写法是跑酷换道的大忌，建议重构为逐帧位移。

5. 跑酷源工程避坑实录：五个最常见的翻车现场

这部分写的是我在不同工程里反复见过的坑。现象、原因、解决一条条过，都是可以直接对着检查的。

5.1 场景里所有物体疯狂抖动或相互穿透

现象：Play 后角色和地面都在原地高频抖动，像帕金森一样。

原因：最常见的是脚本里同时用 Transform.position 和物理引擎（Rigidbody）在控制同一个物体。比如前进用了 Transform.Translate，换道时又给 Rigidbody 的 AddForce，两个系统每帧打架。如果工程里 Player 挂载了 Rigidbody 且 isKinematic 未勾选，任何 Transform 位移都会和物理模拟相互冲突。

解决：二选一，要么保留 Rigidbody 走物理推逻辑，要么去掉 Rigidbody 用纯 Transform 控制。跑酷游戏推荐纯 Transform 控制，物理功能在这个场景里收益不大，反而制造麻烦。如果必须保留 Rigidbody 来做触发器检测，勾选 isKinematic 并继续用 Transform 驱动。

5.2 跳跃后无法落地或落地后瞬间又弹起

现象：角色跳起来后往地面落，但接触地面的一瞬间又被弹回空中，反复弹跳。

原因：跳跃代码里，落地检测用的是 OnCollisionEnter，且没有处理“落地后垂直速度归零”。物理引擎在碰撞发生时会产生反弹，如果脚本在碰撞回调里没有把 verticalVelocity 设为 0，下一帧更新时垂直速度还是朝下的，但角色已经在地面上，于是继续向下推，引擎再次反弹。

解决：落地检测里必须同时处理速度归零和位置微调。常见做法是在 OnCollisionEnter 中判断碰撞平面法线朝上，或者用脚底射线检测。射线检测更稳定：从角色底部中心发射一条向下的短射线，长度略大于碰撞体半高，命中地面层就认为 isGrounded = true。

// 脚底射线落地检测的标准写法 void FixedUpdate() { Ray ray = new Ray(transform.position, Vector3.down); float rayLength = colliderHeight * 0.5f + 0.2f; // 加一点冗余 isGrounded = Physics.Raycast(ray, rayLength, groundLayerMask); if (isGrounded && verticalVelocity < 0) { verticalVelocity = 0f; // 关键：落地的瞬间清零垂直速度 } }

5.3 障碍物生成错乱：有时候两个重叠、有时候半天没有

现象：跑一段路后，前方突然出现两个障碍物完全重叠，或者连续几秒没有任何障碍物，节奏忽快忽慢。

原因：生成逻辑用了纯随机，没有做最小间隔约束。随机数生成在连续调用时可能产生密集的障碍物堆积，也可能长时间不刷。另一个原因是生成器的触发时机和地面片段回收逻辑脱节：新片段生成时，老的片段还没销毁，导致同一位置出现两个片段上的障碍物。

解决：给障碍物生成增加间隔约束。常见做法是维护一个 lastSpawnZ，每次生成时保证 newSpawnZ - lastSpawnZ 不小于最小间距。间距应该根据当前速度换算成时间，保证玩家至少有 0.8 秒反应窗口。代码层面可以用“下一生成点 = 当前生成点 + 最小间距 + 随机余量”的方式，余量范围用 Random.Range(0, extraRange)。

5.4 金币吃不到或吃到了不加分

现象：角色明明穿过了金币模型，但 UI 上的金币数不变，或者只有偶尔能吃到。

原因：金币的触发检测用的是 OnTriggerEnter，但角色身上没有 Collider 且 Collider 的 isTrigger 未勾选，或者金币的 Collider 勾选了 isTrigger 但角色没有 Rigidbody。Unity 的触发检测规则是：两个物体中至少有一个挂载 Rigidbody 且 Collider 是 Trigger，事件才能被触发。跑酷工程里如果把角色做成了纯 Transform 控制且没有 Rigidbody，Trigger 事件根本不会发生。

解决：给角色挂一个 Rigidbody（勾选 isKinematic）或者挂 CharacterController。CharacterController 自带碰撞检测能力，可以触发 OnControllerColliderHit，但不会直接触发 OnTriggerEnter。更可靠的做法是给角色挂一个 Rigidbody isKinematic + Collider（非 Trigger），金币的 Collider 设为 Trigger。这样角色穿过金币时就满足“至少一方有 Rigidbody、一方 Collider 是 Trigger”的触发条件。

5.5 暂停键按下后角色还在往前跑

现象：游戏里做了暂停面板，Time.timeScale 设为 0，但角色依然在移动或者动画继续播放。

原因：脚本里的位移用了不受 timeScale 影响的路径。比如 Update 里的位移乘的是 Time.unscaledDeltaTime，或者动画组件勾选了 Ignore Time Scale。另一个常见原因是协程里的 WaitForSecondsRealtime 不受暂停影响，导致生成器在暂停期间继续刷障碍物。

解决：全局搜索 Time.unscaledDeltaTime 和 WaitForSecondsRealtime，凡是和游戏逻辑相关的都应该换成 Time.deltaTime 和 WaitForSeconds。动画方面，在 Animator 组件里取消勾选 Update Mode 的 Unscaled Time。暂停功能要做干净，最好在 GameManager 里统一维护一个 isPaused 状态，在 Update 开头 if (isPaused) return，比依赖 timeScale 更直观可控。

6. 把源工程改成自己的游戏：换皮、加玩法与性能校准的进阶路径

到这里，你已经能把源工程跑起来、该调的参数也调顺了。最后一章聊怎么基于这份工程做出自己的版本，而不是停留在“会跑”的层面。

6.1 换皮的正确姿势：先换手感再换模型

拿到源工程后，最忌讳一上来就换模型。美术资源替换是体力活，但手感调校才是决定成败的。建议顺序是：先用源工程的模型把速度、跳跃、碰撞体调整到“玩起来舒服”，再做资源替换。换模型时只需要注意几件事：预制体里的 Animator Controller 是否需要重定向骨骼、模型导入设置的 Scale Factor 是否和原模型一致、碰撞体尺寸需要根据新模型的体积重新设置。换个模型后角色变高了，但碰撞体还是老的矮个子尺寸，就会出现头顶穿模的尴尬。

6.2 加一个“滑铲”动作：状态机最小改动方案

很多跑酷工程只有跳跃没有滑铲，加滑铲是对源工程改动最小但效果最明显的玩法升级。实现思路：在 PlayerController 里增加一个 isSliding 状态，按下 S 触发，持续 0.5 秒，期间碰撞体高度减半。注意在滑铲结束时要把碰撞体高度恢复，并防止在滑铲状态下起跳。

// 滑铲状态的最小实现：改碰撞体高度 + 限制起跳 public void StartSlide() { isSliding = true; slideTimer = 0f; // 将碰撞体高度从默认1.2改为0.6，中心点下移0.3保持底部接触地面 capsuleCollider.height = 0.6f; capsuleCollider.center = new Vector3(0, 0.3f, 0); } void Update() { if (isSliding) { slideTimer += Time.deltaTime; if (slideTimer >= slideDuration) { isSliding = false; capsuleCollider.height = 1.2f; capsuleCollider.center = new Vector3(0, 0.6f, 0); } } // 滑铲状态下禁止跳跃 if (Input.GetKeyDown(KeyCode.Space) && isGrounded && !isSliding) { verticalVelocity = jumpForce; isGrounded = false; } }

碰撞体恢复的时机要格外注意：如果恢复发生在地面片段变化、或障碍物判定的一瞬间，高度升高可能直接导致碰撞。所以滑铲结束后做一个短暂的无敌帧（0.1 秒）可以显著减少这种“明明滑过去了却死了”的挫败感。

6.3 性能校准：手机真机上的三档检查

最后是性能。很多工程在编辑器里跑得流畅，打包到手机上就掉帧，多半是下面三件事没做。第一，检查目标帧率：在 Start 里 Application.targetFrameRate = 60。不设置这个，部分安卓机会按屏幕刷新率跑，产生不必要的耗电和发热。第二，检查粒子特效数量：跑酷游戏在角色起跳、落地、收集金币时都会播粒子，如果每个粒子的持续时间太长或者同时活跃的数量过多，CPU 和 GPU 都会被拖住。第三，检查对象池回收逻辑：如果场景里看不到的障碍物没有回收，内存会持续增长，长时间玩会越来越卡。

我一般会在真机上开着 Profiler 跑三分钟，重点看 Scripts 和 Rendering 两个模块的耗时。如果 Scripts 耗时占比过高，优先找 Update 里的每帧字符串拼接、FindObjectOfType 调用这类写法。跑酷工程的脚本数量不多，性能优化空间通常不在架构而在细节习惯。把这些细节过一遍，源工程就真正变成你能驾驭的东西了。

最后说个我自己的习惯：每次拿到一份新工程，第一件事不是看代码，而是把 PlayerController 里的所有 public 字段抄到一个表格里，记录默认值和作用。之后每改一个参数都在表格上标注“为什么改、改完后手感变化”。这样跑几天测试后，你会拥有一份属于自己的参数调校对照表，比任何教程都有用。希望这篇笔记能帮你在跑酷源工程里少走几趟弯路，把时间花在真正有意思的玩法设计上。

本文还有配套的精品资源，点击获取