简介：这是一份面向Unity开发者的无限跑酷游戏完整项目源码，适合想要学习游戏逻辑、角色控制、程序化生成与移动端优化的初中级开发者。资源基于Unity引擎制作，包含完整工程文件与场景设置，核心代码覆盖障碍生成、无限地图循环、角色动画与碰撞检测等模块，并附带源码演示视频，便于对照效果调试。压缩包共2003个文件，大小约600.57MB，其中大量C#脚本、Unity场景与预制体、材质与着色器承担核心逻辑与表现，PNG、PSD等美术资源用于界面和素材替换，Markdown与TXT文档则方便查阅配置说明。整个工程可直接打开，目录结构清晰，便于定位关键代码。已有468人学习，可作为跑酷Demo入门练习或毕业设计底稿，也能从中掌握项目设置、资源管理及移动端跑酷的常见实现思路，参考与复用价值较高。
1. 一套无限跑酷源码，救不了复制粘贴跑通的幻想
拿到一份unity无限跑酷项目源码，绝大多数人的第一反应是解压、用Unity打开、点Play，然后期待一个能跑的Demo出现在Game视图里。实际结果往往是红屏、报错、场景里一片空白，或角色卡在起点一动不动。原因很简单：无限跑酷看起来是个“小游戏”，但它同时涉及动态生成、对象回收、碰撞判定、难度增长和状态机切换，任何一个环节和当前Unity版本的API对不上，整个循环就断掉。源码能给你的不是“一键运行”，而是一套可以拆开理解、逐步修好的框架。这篇文章就按我从零把这类项目跑通、改成品、做成上线版本的真实路径来写，新手能照着走通，熟手可以直接跳到参数和坑位部分。
2. 先搞懂无限跑酷的骨架：生成、回收、判定的循环怎么转
2.1 三种主流跑酷玩法架构，你的源码更接近哪一种
拿到源码的第一件事不是打开场景，而是先看脚本目录和场景里的对象结构。无限跑酷看起来都叫“跑酷”，实现架构其实分三类：纯直线单键跑酷、三车道切换跑酷、开放方向跑酷。不同架构对应完全不同的类设计思路。
纯直线单键跑酷是最常见的一类，玩法上只有跳跃和下落两个操作，障碍物从远处生成，角色固定在一条直线上。它的核心逻辑集中在「角色状态机」和「障碍物生成器」两个类里，代码量少，适合学习，但改装空间有限。三车道跑酷多一个左右切换逻辑，核心在「车道管理系统」，通常是三根x坐标固定的轨道，玩家输入只是换轨道而不是自由移动。开放方向跑酷最少见，角色可以在平面上自由转向，地图生成要复杂得多，一般源码里不太会出现，因为难度和性能门槛偏高。
拿到源码先看入口场景里挂了哪些脚本，再顺着脚本看是否有「生成器」「回收器」「管理器」这类命名的类。无限跑酷项目源码的核心价值就在于把这套生成与回收机制写出来了，看懂它比看懂角色控制更有意义。角色控制是输入响应问题，而地图无限延伸是真问题，跑酷源码最值钱的部分都在后者。
2.2 看懂核心循环：难度拉升与物件生成的联动逻辑
无限跑酷和有限关卡最根本的区别在于：没有终点，且难度须随距离上升。实现难度上升的方式有两种。第一种是速度递增，角色跑得越来越快，单位时间内的障碍物密度不变，但玩家反应时间变短，难度自然上升。第二种是生成密度递增，角色速度不变或小幅变化，但每段距离内的障碍物数量变多、间隔变短。成熟源码通常两者结合，但以速度递增为主。
速度递增的实现有一个陷阱，很多人前期踩过：直接改角色刚体的速度确实能让角色变快，但物理引擎在高速下的碰撞检测会变得不准，角色会频繁出现“穿过障碍物”的现象。更稳妥的做法是给角色一个基础的恒速，通过修改移动速度变量并配合物理引擎的Interpolate设置来平滑变化。生成器如果按固定时间间隔生成障碍物，速度变快后障碍物之间的空间间隔会变大，游戏反而变简单，所以生成器的触发方式通常应该和角色位置绑定：每走过一定距离就生成下一组物件，而不是等固定时间。
难度曲线一般放在一个单独的曲线类里，输入是已跑过的距离，输出是当前速度系数和障碍密度系数。源码中往往会有一个横纵坐标，横轴为距离，纵轴为速度或密度指数，关键是看这个曲线是否足够平滑且封顶。封顶必须存在，否则角色速度会一直飙到物理引擎都没法处理的程度。跑酷源码里难度曲线设计得越清晰，后面调参数时越省事。
2.3 一套典型源码的目录结构长什么样，先从哪里看起
常见做法是把脚本按功能分层：Managers层放游戏管理器、生成器和回收器，Player层放角色控制、碰撞和动画，Environment层放障碍物和地板块预制体，UI层放分数显示和结算面板。拿到源码后先翻Assets/Scripts，对比是否有这四类目录，没有也不代表源码差，但至少要知道每个脚本大概负责什么职责。
打开入口场景后，把Hierarchy面板展开，先找一系列挂脚本的空物体：GameManager、SpawnManager、ObjectPool、UIManager。这是跑酷源码的标配结构。入口场景里的Game物体通常只是空载体，真正的逻辑都挂在Manager上。先看GameManager的Awake和Start方法，就能知道游戏循环从哪里启动，谁负责重置分数，谁负责通知生成器开始工作。
看代码的顺序也有讲究。第一优先级是生成器脚本里的Spawn逻辑，第二是回收器里的回收判断，第三才是角色控制器。角色控制器多数源码已经打磨得比较成熟，而生成与回收是改坏率最高的两部分，先看它们能在后续调试时省掉很多冤枉路。
3. 在本地跑通源码：从选版本到出第一个画面的完整路径
3.1 Unity版本与源码的匹配：先看Package和API兼容
拿到Unity项目源码，最让人头疼的第一关就是版本不匹配。一个用Unity 2021创建的工程，直接拿Unity 2019打开，轻则一堆警告，重则整个渲染管线报错。无限跑酷源码通常不会用到特别新的渲染特性，但程序集定义和包管理器依赖依然有可能不兼容。
打开源码目录前先看ProjectSettings/ProjectVersion.txt，这一行直接写着创建时的Unity版本。如果本机没有完全一致的版本，差一个小版本通常是安全的，比如源码是2021.3.x，用2021.3.y打开问题不大；但跨大版本就风险极高了。源码里如果用到Input System包，旧版项目默认是旧版输入管理器，需要在Player Settings里勾选Active Input Handling来切换。
确认版本后还要检查源码用到的包。打开Window/Package Manager，看是否有报错或缺失项。跑酷源码常见依赖包有三个：Input System、TextMeshPro、Cinemachine。TMP用于UI文字，Cinemachine用于相机跟随，Input System用于新输入轴。源码如果依赖Cinemachine但你本机没有，场景会显示Missing Script但不是脚本文件丢失，而是组件引用的模块缺失，照着Package Manager重新导入即可。
注意一点：很多跑酷源码是从Asset Store购买的，它可能包含代第三方插件。如果导入后出现命名空间冲突或编译器报大量错误，先检查是否有同名类存在于不同目录。常见做法是把第三方插件放入独立文件夹并配程序集定义来隔离，但如果源码制作者没做这一步，冲突就只能自己修了。
3.2 用Git或压缩包导入项目，启动前的必查清单
拿到源码后，导入方式会影响一半的启动成功率。如果源码是Git仓库，不要直接在Unity Hub里点Add Project From Disk指向已经Clone到本地的仓库文件夹，而应采用Git Clone到Unity项目的标准目录后用Hub打开。若仓库是LFS管理的，最好确保本机装好了Git LFS，否则贴图材质会以指针文件形式占位，场景看起来一片紫红。
压缩包解压后打开项目也要留意一个细节：解压路径不能有中文和过深的嵌套。Unity对中文路径的支持虽然这些年好一些了，但插件编译偶尔还是会在中文路径下翻车，尤其是需要调用外部工具的插件。把项目放在一个纯英文短路径下，省去很多玄学问题。
启动前我还习惯做一次目录体检，看几个容易出错的位置：Assets/Scenes下是否有入口场景，Assets文件夹是否和Packages、ProjectSettings同级（如果套了很多层文件夹包，需要把内层项目目录整体移出），Library文件夹是否被意外打包进压缩包。Library文件夹是Unity生成缓存，压缩包里如果带了它，跨机器打开时极易因为缓存与机器的图形API不匹配导致花屏或闪退，删掉它再让Unity重新生成通常是最快解法。
入口场景确认后还要检查Build Settings里的场景列表。有时候源码包含多个场景文件，但Build Settings里只加了主菜单场景，忘了加游戏场景，点击Play确实会先进入主菜单，但点开始游戏后永远是黑屏加载新场景失败。这类问题几乎不看日志查不出原因，所以导入后尽量把场景列表里所有场景加进来。
3.3 跑不起来时的三处排查：报错日志、脚本挂载、场景引用
按下Play按钮后如果世界并没有转起来，先看Console窗口，按错误级别过滤。跑酷源码启动失败集中在三类原因。第一类是脚本编译错误，Console顶部一整片红色，双击任意一条跳转到代码位置，通常原因是无头绪的命名空间缺失或API过时。例如旧版Screen.SetResolution、已废弃的rigidbody.velocity写法在新Unity里会编译不过，改新API即可。
第二类是脚本没有编译错误，但运行时大量NullReferenceException。这类错误常见于GameManager或SpawnManager在Awake里没找到场景中的关键物体，比如引用了某个叫Player的对象但在入口场景里它叫Runner。Unity的序列化引用是按GUID绑定的，对象改名后引用会断开。修复思路是检查Inspector里那些显示为None的引用槽位，重新赋值即可。如果引用槽位太多，写一个纯脚本的引导类来自动查找并赋值会更快。
第三类最隐蔽：场景能跑但视觉异常，比如角色在动但镜头没跟上，或者分数不动、障碍物不生成。这种通常是场景中缺少某些挂载在物体上的辅助组件，比如相机脚本需要一个Target Transform引用，但场景里没指定。打开Hierarchy面板逐一比对关键物体上的组件引用，优先排查GameManager下的Target、Player下的GroundCheck位置、生成器根节点这三处。
还有一个高频怪圈值得提前提醒：场景里嵌套的预制体在编辑器里正常，运行时却消失。冲突源头多半是预制体引用了运行时才会创建的对象，比如路径指示线、特效挂点、动态生成的UI面板。遇到这种情况，直接在游戏模式里用Hierarchy的“锁住”模式观察哪个对象是空的，对照源码里的对象名称处理即可。
4. 把源码改造成自己的玩法：五个必调参数与一组改法
4.1 生成与回收参数：决定手感的第一道闸门
跑酷游戏好不好玩，第一印象来自节奏感，而节奏感由生成参数直接控制。打开生成器脚本，通常能看到几个关键变量：minSpawnDistance（最小生成间隔）、maxSpawnDistance（最大生成间隔）、obstacleGroupCount（每组障碍数量）、firstSpawnOffset（首块障碍离出生点的距离）。
我一般先把minSpawnDistance调大到当前角色跳跃高度的1.5倍以上，这样玩家不会撞上一个几乎无法反应的“贴脸障碍”。maxSpawnDistance控制在角色速度乘以1.2秒，保证玩家不会跑超过一秒都看不到任何障碍，否则游戏会显得“空”。调整方式是开一个小Demo场景，把速度固定为10米每秒，测试障碍间隔时心里换算成秒：间隔10米就是1秒反应时间，间隔5米就是半秒，普通玩家舒适区在0.8到1.2秒。
回收参数同样重要，它决定角色回头看不到“身后残留”的底线。多数回收器是检测物体z坐标小于角色z坐标一定距离后触发。合适的回收阈值是相机视野负方向的边缘线再退后10至15米。阈值调太大会导致远处一堆已不可见的物件持续占用内存，太小则会在相机转头或角色速度激增时出现“预制体消失的瞬间”视觉穿帮。
// 障碍物生成器中的核心生成逻辑（简化示例） void SpawnObstacle() { // 从对象池中取一个障碍物，避免重复Instantiate GameObject obstacle = objectPool.GetPooledObject(); if (obstacle == null) return; // 设定生成位置：z轴 = 当前角色位置 + 前方安全距离 float spawnZ = player.position.z + Random.Range(minSpawnDistance, maxSpawnDistance); obstacle.transform.position = new Vector3(0f, 0f, spawnZ); obstacle.SetActive(true); }代码逻辑本身不复杂：先问对象池要一个可用障碍物，拿不到就直接跳过这一帧；拿到后以角色位置为基准，在前方随机距离处摆放。Random.Range用的是闭区间，所以minSpawnDistance和maxSpawnDistance需要是实际可用的z轴距离值。
调参建议从spawnZ公式下手，把角色速度纳入计算会让生成更均匀：spawnZ = player.position.z + currentSpeed * reactionTime。reactionTime是玩家对下一障碍的预期反应秒数，取0.8到1.0秒是保守值，高手向可以压到0.6秒。这个数值同时也是后续UI提示或音效触发的参考，保持统一就比较好调手感。
4.2 角色控制参数：速度、跳跃、重力与输入延迟
角色控制参数是玩家触碰屏幕后的即时反馈来源，也是源码里最容易改“坏”的地方。跑酷角色大体分物理驱动和代码驱动两类：物理驱动靠Rigidbody的AddForce和Velocity，手感厚重但容易抖动；代码驱动直接改Transform，手感轻快但缺少碰撞互动感。多数源码采用混合方式：水平移动用Transform直接控制，垂直跳跃用物理控制。
最基本的参数组是forwardSpeed、jumpForce、gravityScale。forwardSpeed控制角色前进速度，它直接影响难度曲线上的封顶值，正常区块在8到15之间浮动。jumpForce和重力是一对需要同时调的数值：跳跃高度由jumpForce的平方除以2倍重力决定，而滞空时间由jumpForce除以重力再乘以2。如果只调跳跃力不调重力，角色会“飘”，跳跃后迟迟不下来，手感全无。
常用手感基准参考： - 跳跃高度：2米 - 重力：-15米/秒² - 跳跃初速度：sqrt(2 * 15 * 2) ≈ 7.75 - 滞空时间：2 * 7.75 / 15 ≈ 1.03秒以上是常见游戏手感基准，不是物理模拟的真实重力值。很多源码里用的是gravityScale = 2.5，配合默认物理重力-9.81，实际效果接近-24.5米/秒²，跳跃滞空只有0.6秒左右，手感偏“脆”。调整时把数值代入公式先预演，再去实际场景里试，能少走很多回头路。
输入延迟是另一个常被忽视的痛点。移动端跑酷要求屏幕触碰应立即反应，但源码若使用旧版Input Manager且没有做“输入缓冲”，玩家快速连按跳跃时很容易出现“明明按了却没跳起来”的情况。修改方法是记录一帧内的输入状态，在角色可跳跃窗口期内消费这个状态，而不是要求按下瞬间角色恰好在地面。这个机制对跑酷的重要性甚至超过跳跃力数值本身。
4.3 难度曲线怎么改：让玩家能“再玩一局”的关键
难度曲线直接决定玩家在第几秒流失。曲线太平，玩家觉得无聊；曲线太陡，玩家反复在同一个距离暴毙。真正能跑长线的跑酷源码，难度曲线通常分为三个阶段：前30秒为教学缓冲，障碍密度稀疏，速度缓慢提升；30到120秒为渐进施压，障碍间隔缩短至极限值的60%左右；120秒后进入变化阶段，以周期波动替代持续递增防止疲劳。
float GetCurrentSpeed(float distance) { // 三段时间曲线：缓冲期、爬升期、平台期波动 if (distance < 30f) return 8f + distance * 0.1f; if (distance < 120f) return 11f + (distance - 30f) * 0.03f; float wave = Mathf.Sin(distance * 0.01f) * 1.5f; return Mathf.Clamp(14f + wave, 12f, 16f); }例子中前30米速度从8涨到11，是教学缓冲；30到120米逐步加码到接近14；120米之后用正弦波模拟节奏变化，让长跑玩家在高难度下还能感受到“我有机会喘口气”的窗口期。Mathf.Clamp强设上下限，防止速度失控。
实际调难度时分三步走。第一步固定障碍间隔不变量，只调速度曲线，找到玩家在哪个距离点开始频繁死亡；第二步固定速度曲线，调障碍生成间隔；第三步同时微调两者，让死亡点均匀分布在一个区间，而不是所有玩家都整整齐齐死在同一条线上。最后一步尤其重要，一个被玩家称为“死亡墙”的位置，往往是生成器恰好在同一段距离连续生成密集障碍造成的。
如果源码原本自带难度曲线，不要直接删了重写，先在原曲线上做“拉伸”或“平移”。把原来第30秒的难度值挪到第60秒，等于给玩家多30秒缓冲；把曲线的增幅系数从0.05降到0.03，等于是让整条曲线变得温和整体。源码里找到DifficultyCurve或DifficultyManager之类的脚本，通常只有几行到十几行代码，改起来比想象中简单得多。
4.4 换皮与换规则：从三车道到单键跑酷的改动边界
拿到源码后，大多数人不满足于只调参数，还想换玩法规则。这里要明确一个边界：换皮容易，换核心交互底层难。换皮就是替换角色模型、障碍物模型、背景、音效、UI皮肤，这些基本不影响代码逻辑，只要保持预制体的尺寸和碰撞体形状不变即可。
从三车道改成单键跑酷，要动的逻辑就不止表面一层了。三车道跑酷的核心是车道切换管理类，它监听横向输入，把角色移动到目标车道的x坐标。改成单键跑酷意味着砍掉横移逻辑，角色固定在中心x位置，只保留跳跃。操作上需要做三件事：一是删除或注释掉车道管理器中的移动分支，二是把玩家输入从“左右切换”改成“单键跳跃”，三是把障碍物的生成范围从三条车道收敛到一条。生成器的laneIndex随机逻辑在单键模式下无意义，要强制固定为一个值。
反过来，从单键改成三车道，工作量更大。除了新增车道管理系统，还要给角色增加横移动画，给障碍物生成器增加随机车道逻辑，给地面增加至少三根轨道的视觉区分。所谓“换规则”，本质上是在源码现有框架之外增加一个新的控制维度，这部分改造需要你对输入管理器、动画状态机、碰撞层都有一定掌握，建议先在副本项目上做实验，别在主项目上直接改。
5. 跑酷源码实操避坑：九个真实翻车现场与修复记录
5.1 场景里全是Missing Script，预制体整体失效
现象：打开场景后，Hierarchy里面大量物体挂着一行淡黄色警告标识，点开一看组件是缺失状态。直接Play，角色和障碍物全部消失或静态不动。
原因：脚本文件被移动或重命名后，Unity在场景和预制体里的引用彻底断裂。预制体与场景物体引用脚本用的是GUID和FileID，脚本文件名变了，GUID就失效，Unity不知道这个组件曾经是什么。
解决：从源码历史版本或备份中找回原脚本名，放回原目录。如果没有备份，只能逐个检查Missing Script组件的原引用数据，用文本编辑器打开场景YAML查找对应的GUID，再反查新脚本的.meta文件GUID是否一致。教训是拿到源码后先复制一份，不要直接在唯一副本上做重命名操作。
5.2 TextMeshPro字体丢失，UI文字变成红色方块
现象：游戏能跑，但所有UI文字显示为一个个红色菱形方块，分数和菜单标题全是乱码。
原因：TMP的字体资源没有随项目迁移，或者动态字体库从未生成。TMP字体资源（.asset文件）存放在Assets/TextMesh Pro/Resources/Fonts & Materials下，如果源码发布时漏了这个目录，就必定出现红方块。更隐蔽的是字体文件存在但TMP设置里引用的资源是旧GUID，打开Prefab后引用依然断开。
解决：确认Package Manager里TextMeshPro已安装，随后在Window/TextMeshPro/Font Asset Creator里重新生成一个默认字体资源，再全局替换场景和预制体中的字体引用。替换时用“查找并替换所有TMP组件字体”的批量处理工具，别一个一个手动改，四十个UI节点手改会让你怀疑人生。
5.3 碰撞体检测时好时坏，撞上空气却判定Game Over
现象：玩家明显和障碍物擦身而过，屏幕却已经弹出失败界面；反过来，玩家穿过了障碍物但没有任何碰撞反应。
原因：角色和障碍物使用了错误的碰撞层，或者碰撞体尺寸与模型不匹配。跑酷源码中常见做法是角色挂一个BoxCollider作为“受击判定”，障碍物也有各自的Collider，且使用专用碰撞层避免与地面、装饰物发生无意义计算。如果层设置被重置，角色可能和不该碰的物件碰了，该碰的反而被忽略。
解决：打开Edit/Project Settings/Physics，检查碰撞层矩阵，确保角色层只与障碍物层和地面层响应。再检查角色的Collider尺寸是否覆盖了视觉模型的主要区域，建议开启Unity的“调试碰撞体”可视化，在Scene视图里直接看绿色线框。跑酷角色Collider的高度建议取模型高度的80%左右，底部留出少量地面容错，受击判定会更合理。
5.4 切场景后变量没重置，分数越玩越离谱
现象：从主菜单进入游戏第一次正常，Game Over后点击“再来一局”，分数从上次的数值继续累加，或生成器工作异常，障碍物叠成一团。
原因：GameManager和分数管理器的静态变量在场景切换之间保留了旧值。跑酷源码为了跨场景传数据，常把分数或游戏状态做成本地静态字段，但忘记在关卡启动时重置。
解决：在游戏入口脚本的OnEnable或Start里显式调用重置方法，把当前分数、速度系数、生成距离、对象池状态全部清一遍。我习惯在GameManager里单独写ResetGameState()，并确保它只在真正开始游戏那帧调用一次，不想意外触发时可以在调用前加isGameStarted守卫条件。这个习惯治好了我大半的“再来一局就翻车”问题。
5.5 移动端重力方向对齐问题，屏幕角度变了判定就歪
现象：游戏在编辑器横屏运行正常，打包到手机后竖屏状态下角色跳跃方向偏斜，重力方向与视觉世界不一致。
原因：手机屏幕方向变化时，Input的加速度计数据也被重新映射，但跑酷游戏物理世界坐标系没同步。多数跑酷源码默认横屏设计，若你调整了Player Settings里的Default Orientation，而没有同步修改重力感应逻辑，就会出这类错。
解决：跑酷类游戏一般锁死横屏，Player Settings里Orientation设为LandscapeLeft或LandscapeRight，并取消Auto Rotation。如果一定要支持竖屏，必须重写重力输入方向的映射代码，把屏幕坐标转换到世界坐标。这个改动涉及整个控制层，属于“规则更换”级别，非必要不动。
5.6 源码自带的SDK或资源包在本地报错
现象：导入项目后Console里连续出现关于第三方SDK的红色报错，比如广告、统计、云存档相关的脚本全部编译失败。
原因：源码在制作时使用了特定版本的SDK，新环境下SDK的依赖包版本或API有变，或者某些SDK需要Android/iOS原生环境才能编译。
解决：如果你不需要SDK功能，直接把相关脚本和Plugins目录下的对应库文件全部禁用或删除，游戏本体逻辑通常不受影响。如果需要，去对应SDK官网重新下载适配当前Unity版本的包。这里强调一个经验：跑酷源码的广告和统计分析代码往往是整体项目里耦合最差的部分，能用扩展方式接入就不要把SDK和GameManager写死在一起，否则后续每次版本更新SDK都是一场硬仗。
5.7 对象池里的物体只增不减，内存悄悄涨爆
现象：游戏运行超过三分钟后，Profiler里的实例数量持续上升，帧率逐渐下降。
原因：回收器和对象池的实现有问题。典型的错误是回收时只调用SetActive(false)却没有把物体移回池子列表，或者生成时绕过池子直接Instantiate。被SetActive(false)的物体虽然不渲染，但只要被场景引用，依然占用内存和层级遍历时间。
解决：在对象池脚本里加一个自检方法，打印当前池内物体数量和场景中激活物体数量。如果激活数一直在涨，重点排查SpawnManager是否有分支绕过了池子。另一个常见做法是在回收时把物体父级设为池子根节点，生成时再挂到场景节点下，父级隔离能显著减少运行时遍历开销。
5.8 音频不循环或播放时机错位
现象：背景音乐在角色死后整个游戏静音，重生后音乐重新从头播放，或者音效提前半秒响起。
原因：音频源挂在了被销毁的物体上，或事件触发了错误的播放时机。跑酷里背景音乐应该挂在常驻的GameObject（通常是GameManager）上，而不是挂在角色预制体上。死亡后角色被禁用，音频源也跟着停止。
解决：把BGM AudioSource移到GameManager物体上，并设置循环播放；死亡时只暂停，不用Stop，重开时调用Play恢复。音效延迟问题则检查触发音效的帧顺序，碰撞回调发生在物理更新阶段，UI更新在渲染阶段，中间有顺序差，不要把音效播放放在协程里，放在OnCollisionEnter回调里最干净。
5.9 不同分辨率下UI错位，手机适配靠硬编码
现象：编辑器16:9画面正常，打包到全面屏手机上，分数显示跑出屏幕外，按钮位置偏离，背景图被拉变形。
原因：UI锚点、Canvas缩放模式、背景图裁切策略都没适配。跑酷项目的UI通常包含HUD分数、暂停按钮和结算面板，如果Canvas的Canvas Scaler没有正确设置，换分辨率就会全面崩盘。
解决：Canvas Scaler的UI Scale Mode选“Scale With Screen Size”，参考分辨率设你测试机的主流尺寸，比如1080x2400。锚点要全屏幕布局，分数顶部居中、暂停按钮右上角、结算面板居中，不要用绝对坐标。背景图用Image组件的“Preserve Aspect”勾选，配合背景层的RectTransform铺满安全区。
6. 最后一个交付级技巧：让跑酷不像Demo的三个手感改造
Unity里能跑的游戏一大堆，但“能跑”和“手感合格”之间隔着一整条街。跑酷源码最常见的demo感来自三个地方：角色加速太生硬、镜头固定不动、输入响应有延迟。前两个问题在代码层面就能解决。
镜头是第一个要处理的。源码里如果只有一句简单的transform.position = player.position + offset跟随，画面在角色左右切换或跳跃时会显得非常机械，因为没有任何平滑过渡。常见做法是把相机改成LateUpdate中跟随，加上Vector3.SmoothDamp或Quaternion.Lerp。跳跃时镜头要有一点向下俯视的配合，制造速度感；角色落地时镜头要微微下压再恢复，对应重量感。这些效果不需要Cinemachine也能写，只是Cinemachine的Timeline控制更顺手。
void LateUpdate() { // SmoothDamp让镜头有滞后感，而不是死死钉住角色 Vector3 targetPos = player.position + offset; transform.position = Vector3.SmoothDamp( transform.position, targetPos, ref velocity, smoothTime); }smoothTime是镜头反应速度，0.15秒偏紧，0.3秒偏松。跑酷场景我推荐0.2秒左右，既能保留移动感又不会让玩家觉得镜头在晃。保存ref velocity可以在角色急停时自然产生镜头惯性，这个细节是廉价但高效的品质提升点。
镜头的第二个细节是提前量。相机跟随点不应正对角色中心，而应向角色前方偏移一段距离，让玩家能看到更多的前方路况。跑酷游戏玩家常说的“看不到前方所以撞了”，大多数不是生成密度问题，而是相机视距不够。把offset.z加大5到10个单位，或者让相机跟随点落在角色前方3到5米处，障碍反应的舒适度会明显上升。
第二个改造是跳跃输入的缓冲。普通写法是按钮按下时判断IsGrounded，不是地面就不跳。这会导致玩家在落地前0.1秒按下跳跃却没反应，在高速跑酷里这种输入丢失会造成极强的挫败感。加一个输入缓冲队列，按住跳的输入保留0.15秒，角色落地瞬间自动消耗这个缓冲执行跳跃，手感和原生移动游戏体验基本一致。
第三个改造是“脚步-障碍”判定窗口。很多跑酷源码的跳跃判定是瞬时的，即角色刚离地就立刻可以再次落地判定，导致玩家快速双击时，第一次跳还没结束就被判断为二次跳，角色抽搐。常见做法是增加一个跳跃冷却时间，或者用一个简单的状态锁：isJumping为true时忽略跳跃输入，直到isGrounded重新为true且缓冲时间已过。把这个逻辑和上面的输入缓冲组合起来，跳跃手感才算完整。
最后说个习惯性建议：开启对象池的“预热”功能。跑酷游戏一启动就生成大量可用物体塞进池子，比运行时逐步Instantiate对帧率平稳性有利得多。一次启动加载30个预制体可能让首屏卡半秒，但在游戏过程中换取的帧率稳定性和内存可预测性，对跑酷这种需要长时间连续运行的玩法类型来说完全值得。这也是我在无数个项目中踩出来的教训，希望帮到你。
本文还有配套的精品资源，点击获取
