拓冰网站定制 
如果你正打算做一款休闲跑酷游戏或者已经尝试过跑酷品类开发却始终觉得“手感差一点”“细节不到位”那么这篇文章值得你停下来看完。它记录的并不是什么高深莫测的游戏架构而是一个跑酷项目第二天的开发进度场景框架搭到什么程度角色控制怎么做才能更跟手障碍物和跑道的生成该怎么组织。跑酷游戏看着简单真正动手写起来你会发现入口处全是细节问题。入局跑酷游戏的门槛不高跑通一个Demo可能只需要一个晚上。但如果你只看过几个教程就自己上手大概率会遇到这样几个问题角色跳跃高度飘忽不定、跑道延伸不连贯、碰撞判定时灵时不灵、手机端的操作响应延迟明显。这些问题如果放到项目中期再去修会非常痛苦。Day 2 要做的就是把最容易被忽略的核心框架定好Player 控制、跑道生成、碰撞与计分。这三块搭稳了后面加入道具、皮肤、无尽模式、广告变现都只是时间问题。本文会从跑酷游戏最底层的原理讲起拆解一个可供复用的 Unity 实现方案包含完整可跑的代码示例和常见问题排查。无论你是第一次做跑酷游戏还是正处于项目重构阶段这篇文章的核心判断是一致的跑酷游戏的竞争力从来不在玩法创意而在于基础框架的稳定性和角色的操控手感。1. 跑酷游戏到底难在哪里跑酷这类休闲游戏在需求文档里往往只写三件事角色往前跑、玩家控制跳跃和滑铲、躲避障碍物获取金币。需求看着简单但把它翻译成技术方案时很多新手会踩进同一个坑把所有逻辑塞进一个 Player 脚本里场景和障碍物全部靠美术手摆碰撞体尺寸随意设置结果就是Demo能玩、上线后体验稀碎。跑酷类游戏的技术难点实际上集中在四个方面第一角色移动方式的选择。跑酷游戏通常不使用真正的物理引擎来驱动角色前进而是让世界跑道、障碍物、装饰物向玩家移动角色本身在原地做跑动动画。这样做的好处很明显角色速度计算更稳定、碰撞判定更容易控制、对不同性能手机更友好。真实物理移动会让角色受到撞击力、摩擦力等不确定因素干扰这对追求“确定性手感”的跑酷游戏来说是致命的。第二控制响应的及时性。玩家点击屏幕的瞬间要完成跳跃或滑铲如果响应延迟超过一两帧玩家的直觉就会被打破。这个问题的根源往往不在代码速度而在于动画切换的过渡、状态机的设计以及输入读取的时机。第三障碍物排列的逻辑。如果障碍物是纯随机生成的很容易出现连续三个跳跃障碍或者跳跃后紧接着滑铲死角这样的“死局”玩家会认为游戏不公平。跑酷游戏的随机难度一定是有约束的随机。第四碰撞框的精度。玩家看到的角色模型是一回事碰撞盒又是另一回事。碰撞盒太大玩家明明躲过了却判定撞上碰撞盒太小看起来撞上却还能跑。如何调节碰撞盒大小和玩家感知之间的关系是跑酷手感的核心秘密之一。所以Day 2 的开发目标不是写一堆功能点而是把上述四件事的框架搭好。2. 跑酷游戏的核心架构设计跑酷类游戏的代码架构并不复杂市面上大多数同类产品都可以抽象为三个模块Player 模块负责角色状态机、跳跃、滑铲、下落、转向、动画切换和碰撞回调。Track 模块负责跑道的无限延伸、场景碎片的循环利用、障碍物和金币的生成与回收。Game Flow 模块负责游戏状态切换、得分计算、暂停/恢复、Game Over 处理以及UI事件。很多新手会忽略第三层把得分、UI、游戏状态都直接写在 Player 里。Demo 阶段看不出问题一旦接入广告、分享、排行榜、复活机制Player 脚本会膨胀到一个几千行的“上帝类”改一行动画逻辑都可能影响计分。推荐的项目目录结构如下Assets/ ├── Scenes/ // 场景文件 │ └── MainGame.unity ├── Scripts/ │ ├── Core/ // 游戏状态机、事件中心 │ ├── Player/ // 角色控制、动画、碰撞 │ ├── Track/ // 跑道生成、障碍物生成 │ └── UI/ // 计分、暂停、结算 ├── Prefabs/ │ ├── Player/ │ ├── TrackParts/ // 跑道块 │ └── Obstacles/ // 障碍物 ├── Art/ // 美术资源 └── Settings/ // 配置数据核心原则只有一条把角色、赛道、游戏流程三者解耦。角色不需要知道分数怎么算赛道不需要知道角色当前在哪个状态游戏流程只需要监听各模块的事件。这样后续每个独立模块都能单独替换和测试。3. 环境准备与前置条件本次开发基于 Unity 2021.3 LTS长期支持版本这个版本在移动端跑酷类游戏的开发上足够稳定Android 和 iOS 构建工具链都比较成熟。如果你使用的是更高版本本文涉及的核心 API 没有大的变化思路依然通用。如果在实际项目中用的是不同版本请以你项目实际版本为准这里重点演示的是通用实现思路。开发前需要确认以下几点操作系统Windows 10/11 或 macOS 均可。Unity Hub建议通过 Unity Hub 管理 2021.3 LTS 版本。构建目标Android 或 iOS需要提前安装对应的构建模块。版本控制工具Git以及 LFS大文件存储用于管理美术和音频资源。创建一个名为 TomCatRunner 的项目模板选择 3D Core。为什么要选 3D 而不是 2D跑酷类游戏的表现形式虽然看起来是“平面往前跑”但角色模型、障碍物深度、金币旋转等元素在 3D 空间中实现更自然相机跟随也更容易调整。后面如果想要 2.5D 的视觉效果直接在 3D 场景中调整相机角度即可。项目创建完成后建议立即调整几个关键设置第一步设置输入机制。跑酷游戏的输入主要依赖触屏或鼠标不需要重力感应。打开Edit Project Settings Player Android/iOS设置确认输入处理方式为Input System (Old)或Input Manager本次示例使用旧版 Input Manager因为它最简单、最容易理解。如果你用的是新版 Input System需要注意InputAction的配置方式。第二步固定帧率。跑酷游戏对帧稳定性要求很高打开Edit Project Settings Quality在Other选项里可以关闭阴影或调整阴影质量。实际项目里更推荐在代码中设置目标帧率// 文件路径Assets/Scripts/Core/GameSettings.cs using UnityEngine; public class GameSettings : MonoBehaviour { private void Awake() { // 手机端目标帧率设为 60不要依赖默认值 Application.targetFrameRate 60; // 关闭垂直同步避免部分安卓设备强制锁 30 帧 QualitySettings.vSyncCount 0; } }这里的核心原因是跑酷游戏的碰撞和位移计算依赖Time.deltaTime如果帧率忽高忽低角色跳跃的弧线、障碍物接近的速度都会时快时慢玩家会感觉“手感很不稳”。锁帧能较大程度缓解这个问题但设备性能不足时仍需配合对角色碰撞的处理来兜底。4. 场景搭建与跑道生成逻辑跑酷游戏的地图不需要美术摆一整条赛道而是由多个跑道块拼接而成。每个跑道块是一个 Prefab长度固定内部包含地面、装饰物、可能的障碍物生成点。当角色向前“跑动”时检测到即将走完当前跑道块就生成下一段跑道块并回收身后的跑道块。这个概念称为“对象池 预制体拼接”是跑酷游戏里最成熟的地图加载方式。4.1 跑道块构成新建跑道块 Prefab命名为Track_Base结构如下Track_Base ├── Ground // 带 BoxCollider 的地面 ├── LeftBound // 左侧边界隐形墙体用于防止角色跑出地图 ├── RightBound // 右侧边界同理 └── Decorations // 装饰物容器树木、路牌可放多个子物体跑道块长度建议设置为固定值比如30f。这个长度后面会被生成器用到。地下的 Ground 只需要一层薄的 BoxCollider碰撞体越多物理计算就越浪费。装饰物不要挂碰撞体宁可让玩家的视线穿过它也不要让不必要的碰撞参与计算。4.2 跑道生成器跑道生成器的核心职责就是维护一个“当前活动跑道块”的队列。它不断生成新块、移除旧块同时把障碍物生成的任务交给障碍物生成器。// 文件路径Assets/Scripts/Track/TrackSpawner.cs using System.Collections.Generic; using UnityEngine; public class TrackSpawner : MonoBehaviour { [Header(跑道块预制体)] public GameObject trackPrefab; [Header(每次生成的跑道块数量)] public int poolSize 5; [Header(跑道块长度需与预制体长度一致)] public float trackLength 30f; private ListGameObject activeTracks new ListGameObject(); private float spawnZ 0f; private void Start() { // 启动时先生成 poolSize 段跑道保证开局不穿帮 for (int i 0; i poolSize; i) { SpawnTrack(); } } private void Update() { // 当最后一段跑道快被走完时补充新跑道 // 用角色 z 坐标与跑道总长的差值作为判定条件 } private void SpawnTrack() { GameObject track Instantiate(trackPrefab, transform); track.transform.position new Vector3(0f, 0f, spawnZ); spawnZ trackLength; activeTracks.Add(track); // 如果当前跑道数量超出保持值移除最早的一段 if (activeTracks.Count poolSize) { RemoveFirstTrack(); } } private void RemoveFirstTrack() { GameObject old activeTracks[0]; activeTracks.RemoveAt(0); Destroy(old.gameObject); } }这样实现的优点是无论游戏运行多久场景中存活的跑道块数量始终不超过poolSize1内存占用非常稳定。Destroy在频繁调用时会产生性能压力实际工程项目可以换成对象池回收机制这是 Day 4 之后要考虑的优化点。4.3 障碍物生成策略障碍物不能直接挂在跑道块上由美术摆设那样会让每一局的路线完全一致。更合理的方案是跑道块提供一个“播种接口”由障碍物生成器在跑道块被激活时根据当前难度等级和一条有约束的随机规则把障碍物摆进去。先看一个最简单的实现// 文件路径Assets/Scripts/Track/ObstacleSpawner.cs using UnityEngine; public class ObstacleSpawner : MonoBehaviour { [Header(障碍物预制体)] public GameObject lowObstacle; // 需要跳跃的矮障碍 public GameObject highObstacle; // 需要滑铲的高障碍 [Header(生成范围)] public float minDistance 5f; public float maxDistance 12f; private float nextSpawnZ 10f; private int lastPatternIndex -1; public void SpawnObstacle(float startZ, float trackZLength) { while (nextSpawnZ startZ trackZLength) { // 随机选择障碍类型0 需要跳跃1 需要滑铲 int patternIndex Random.Range(0, 2); // 避免连续出现同类型导致玩家操作疲劳 if (patternIndex lastPatternIndex) { patternIndex (patternIndex 1) % 2; } lastPatternIndex patternIndex; GameObject obstacle PickObstacle(patternIndex); PlaceObstacle(obstacle, nextSpawnZ); nextSpawnZ Random.Range(minDistance, maxDistance); } } private GameObject PickObstacle(int index) { return index 0 ? lowObstacle : highObstacle; } private void PlaceObstacle(GameObject obstacle, float z) { GameObject go Instantiate(obstacle); go.transform.position new Vector3(0f, 0f, z); } }这里的约束规则很关键连续不会出现两次同类型的障碍物。这个规则就是跑酷游戏“公平性”的底层实现。玩家跳过矮障碍后下一段大概率是滑铲这样给出手指的切换留出了反应时间。障碍物生成时还需要考虑“死局”问题。比如跳跃障碍后紧接着立刻出现上压障碍玩家落地瞬间根本来不及反应。因此生成障碍物时还要引入一个“安全距离”的概念——当上一个障碍物距离当前生成位置过近时跳过这次生成直到距离放宽。5. 玩家控制核心代码实现玩家控制是跑酷游戏最核心的部分。这一节会给出一个可运行的基础版 PlayerController 框架包含状态机、跳跃物理、滑铲和碰撞回调。代码力求精简方便读者理解核心逻辑。5.1 角色基础状态与垂直移动跑酷游戏中的“跳跃”其实是数学抛物线不依赖 Unity 物理引擎的刚体。这样做的好处是省略重力加速度、摩擦力等物理因素的干扰跳跃高度和时间完全可控。// 文件路径Assets/Scripts/Player/PlayerController.cs using UnityEngine; public class PlayerController : MonoBehaviour { [Header(移动参数)] public float jumpHeight 5f; public float jumpDuration 0.5f; public float slideDuration 0.8f; public float horizontalSpeed 8f; [Header(状态检测)] public Transform groundCheck; public LayerMask groundLayer; private enum PlayerState { Running, Jumping, Sliding, Dead } private PlayerState state PlayerState.Running; private CharacterController controller; private float verticalVelocity 0f; private float stateTimer 0f; private float currentTrackZ 0f; private void Awake() { controller GetComponentCharacterController(); } private void Update() { if (state PlayerState.Dead || state PlayerState.Sliding) { return; } HandleInput(); ApplyVerticalMovement(); } private void HandleInput() { if (Input.GetButtonDown(Jump) state PlayerState.Running) { state PlayerState.Jumping; stateTimer jumpDuration; // 跳跃初速度根据目标高度计算 verticalVelocity (2f * jumpHeight) / jumpDuration; } else if (Input.GetButtonDown(Fire1) state PlayerState.Running) { StartSlide(); } else if (Input.GetButtonDown(Jump) state PlayerState.Jumping) { // 空中再次点击可加速下落增强操作感 stateTimer 0f; verticalVelocity -4f; } } private void ApplyVerticalMovement() { if (state PlayerState.Jumping) { stateTimer - Time.deltaTime; verticalVelocity - (2f * jumpHeight) / (jumpDuration * jumpDuration) * Time.deltaTime; if (stateTimer 0f) { verticalVelocity 0f; state PlayerState.Running; stateTimer 0f; } } else if (state PlayerState.Running) { verticalVelocity IsGrounded() ? -2f : -9.8f * Time.deltaTime; } // 应用垂直位移 Vector3 move new Vector3(0f, verticalVelocity, 0f) * Time.deltaTime; controller.Move(move); } private bool IsGrounded() { return Physics.CheckSphere(groundCheck.position, 0.1f, groundLayer); } private void StartSlide() { state PlayerState.Sliding; stateTimer slideDuration; // 滑铲时降低碰撞体高度后续可通过动画配合缩放 Vector3 center controller.center; center.y 0.5f; controller.center center; controller.height 1f; Invoke(nameof(EndSlide), slideDuration); } private void EndSlide() { state PlayerState.Running; Vector3 center controller.center; center.y 1f; controller.center center; controller.height 2f; } }这个版本的跳跃实现不需要 Rigidbody只用CharacterController 手动垂直速度。verticalVelocity相当于现实中跳跃速度在竖直方向的分量跳跃过程中它被一个恒定的减速项拉回地面。数学上等价于竖直上抛运动但代码里不涉及任何物理引擎的干扰因此跳跃轨迹极其稳定。空中二次点击加速下落是非常关键的手感细节。很多跑酷游戏让人觉得“飘”原因就是跳跃下落过程太长玩家明明感觉角色已经该落地了画面里却还在空中。加入快速下落机制后玩家对节奏的掌控感会显著提升。5.2 水平变道操作跑酷游戏通常有三条或五条跑道玩家通过左右滑动屏幕切换跑道并躲避障碍物。这个功能的核心是水平方向的平滑移动而不是直接瞬移过去。直接瞬移看起来很不自然还会破坏玩家对角色位置的预判。// 文件路径Assets/Scripts/Player/PlayerController_Lane.cs // 该文件是 PlayerController 的部分类扩展需要声明为 partial class using UnityEngine; public partial class PlayerController : MonoBehaviour { public int currentLane 1; // 当前跑道0 / 1 / 2 public float laneWidth 2.5f; public float laneChangeSpeed 10f; private Vector3 targetLanePosition; private void HandleLaneInput() { if (Input.GetButtonDown(Horizontal)) { float x Input.GetAxisRaw(Horizontal); if (x 0 currentLane 0) { currentLane--; } else if (x 0 currentLane 2) { currentLane; } } // 在 Update 外部每帧调用确保移动平滑 Vector3 goal new Vector3((currentLane - 1) * laneWidth, transform.position.y, transform.position.z); transform.position Vector3.Lerp(transform.position, goal, laneChangeSpeed * Time.deltaTime); } }实现思路是玩家按下左/右键时改变目标跑道编号然后把当前位置向目标位置做线性插值。Lerp的系数带上帧率修正后无论设备帧率是高是低变道速度都保持一致。注意这里的横向移动不能直接修改CharacterController.Move的 y 分量否则会和跳跃计算冲突。更稳妥的做法是按需在 Update 中调用位置插值或者把横向移动也交给controller.Move统一处理。还需要注意一点变道过程中需要短暂屏蔽输入否则玩家疯狂按键时角色会在跑道之间高频抖动既影响画面也不利于碰撞判断。实际项目中可以引入一个变道冷却时间比如 0.15 秒内不允许连续变道。5.3 动画状态同步状态机的切换必须同步给 AnimatorAnimator 的参数建议使用触发器或布尔变量组合而不是枚举直接赋值。// PlayerController 内部补充 private Animator animator; private void Awake() { controller GetComponentCharacterController(); animator GetComponentInChildrenAnimator(); } private void UpdateAnimation() { switch (state) { case PlayerState.Running: animator.SetBool(Running, true); animator.SetBool(Jumping, false); animator.SetBool(Sliding, false); break; case PlayerState.Jumping: animator.SetBool(Running, false); animator.SetBool(Jumping, true); break; case PlayerState.Sliding: animator.SetBool(Running, false); animator.SetBool(Sliding, true); break; } }这里有一个常见的坑如果使用Animator.CrossFade直接播放动画频繁切换状态会造成动画过渡冲突。正确的做法是给动画状态机设置合理的过渡时间和过渡条件把跳跃、滑铲、跑动的过渡间隔都控制在 0.05 到 0.1 秒内让动画切换干脆利落。6. 计分系统与碰撞判定计分系统在很多跑酷教程里往往只是一句话带过但它实际上是“成就感”的核心来源。Day 2 阶段先实现一个简单可靠的计分框架跑动距离分和金币分。6.1 计分管理器// 文件路径Assets/Scripts/Core/ScoreManager.cs using UnityEngine; using UnityEngine.Events; public class ScoreManager : MonoBehaviour { public static ScoreManager Instance; public int CurrentScore { get; private set; } public int CurrentCoins { get; private set; } public float RunDistance { get; private set; } public UnityEventint onScoreChanged; public UnityEventint onCoinChanged; private void Awake() { if (Instance null) { Instance this; } else { Destroy(gameObject); } } private void Update() { if (!GameFlow.Instance.IsPlaying) return; float deltaDistance 10f * Time.deltaTime; RunDistance deltaDistance; AddScore((int)(deltaDistance * 10f)); } public void AddScore(int value) { CurrentScore value; onScoreChanged?.Invoke(CurrentScore); } public void AddCoin() { CurrentCoins; onCoinChanged?.Invoke(CurrentCoins); } }分数来源分两部分一部分是距离分持续累积另一部分是金币分获得时直接加上去。ScoreManager使用单例模式但通过事件而不是“其他脚本主动查分数”的方式来通知 UI这样 UI 层只需要监听事件不需要知道计分细节。6.2 碰撞判定跑酷游戏的碰撞判定要区分两类角色碰到障碍物游戏结束。角色碰到金币获得奖励。障碍物碰撞障碍物预制体应该挂一个Obstacle标签或脚本组件角色进入触发器时判断是否为障碍物。// 文件路径Assets/Scripts/Player/PlayerCollision.cs using UnityEngine; public class PlayerCollision : MonoBehaviour { private void OnTriggerEnter(Collider other) { if (other.CompareTag(Obstacle)) { // 通知 Player 进入死亡状态 GetComponentPlayerController().Die(); } else if (other.CompareTag(Coin)) { ScoreManager.Instance.AddCoin(); Destroy(other.gameObject); } } }因为使用了CharacterController碰撞事件会以OnTriggerEnter形式触发障碍物要挂在Trigger类型的 Collider 上。这个设计把碰撞职责从PlayerController中分离出来以后给角色加护盾、磁铁等道具时直接扩展碰撞脚本就行。这里有很重要的性能调优点不要给金币使用 MeshCollider一定要用 BoxCollider 或 SphereCollider并勾选Is Trigger。每个金币的碰撞检测范围不用精确贴合模型可以稍微大一点让玩家“擦边吸到金币”的感觉更明显这是提高游戏爽感的设计也是物理上的容错设计。利用碰撞高度差优化手感很多玩家抱怨“明明滑铲了还是撞上高障碍”原因往往是碰撞盒没有在滑铲时跟着动画同步变更。在 5.1 节的代码里我们已经处理了滑铲时controller.height和controller.center的变更但要注意把这次变更和 Animator 的动画播放同步。如果动画已经播到滑铲姿势但碰撞盒还没降下来就会出现“模型趴下了、碰撞体还站着”的穿帮效果。判断统一在动画事件里完成// 在 Animator 事件中调用 public void OnAnimationSlideStart() { SetColliderForSlide(); } public void OnAnimationSlideEnd() { SetColliderForRun(); }7. 运行结果与效果验证搭好上述框架后运行 Unity 场景你会看到角色持续向前移动跑道块依次铺开障碍物和金币按规则生成在路线上。按空格键执行跳跃按 Ctrl 或自定义按键执行滑铲左右方向键切换跑道。正常情况下的验证标准如下连续跑动 30 秒以上场景内 GameObject 数量保持相对稳定不会无限增长。跳跃最高点看起来在角色胸口位置不和头顶碰撞体高度冲突。障碍物连续出现时不存在两个同类型障碍紧贴的情况。金币盒子的触发范围略大于视觉大小玩家擦边也能吃到金币。撞到障碍物后角色停留在碰撞点而不是穿模后继续前进。如果验证中发现跳跃高度不正常第一步应该检查jumpHeight和目标帧率设置。跳跃高度的计算依赖Time.deltaTime如果手机端帧率低于 30跳跃的实际高度会比理想值偏小。更稳健的方案是把跳跃改为基于时间的速度积分彻底排除帧率波动的影响。8. 常见问题与排查思路问题现象可能原因排查方式解决方案跳跃高度忽高忽低帧率波动影响Time.deltaTime计算查看 Profiler 中的帧率曲线固定Application.targetFrameRate或改用基于时间的跳跃模型角色卡在障碍物边界使用CharacterController.Move时速度过快发生隧穿检查单帧最大位移量将最大移动速度限制在 20m/s 以内或对高速物体分段检测滑铲后碰撞体恢复异常Invoke被多次触发状态没同步打印状态日志检查StartSlide是否被重复调用在Update中统一基于stateTimer做状态切换不使用Invoke跑道块之间出现裂缝跑道块长度配置和生成间距不一致打印生成位置和预制体长度统一读取预制体长度而不是手动填写trackLength金币无法触发判定OnTriggerEnter没有调用检查角色是否挂了CharacterController检测金币是否挂了Trigger Collider角色必须挂CharacterController才能触发触发器事件障碍物连续出现同类型随机规则没生效打印生成日志实现“上一次类型”检测同类型时强制切换这里重点解释一下最容易忽略的“隧道效应”问题。CharacterController.Move在移动距离过大时可能会直接穿过薄碰撞体导致角色明明在视觉上撞到了障碍物却被判定为通过。这个问题在高速跑酷场景中非常常见因为在游戏后期角色速度越来越快单帧位移量会不断增大。解决思路有三个层次第一限制最大速度让单帧位移不要超过最小碰撞体厚度的两倍第二把障碍物碰撞体做成多个小盒子的组合而不是一个很薄的单片第三在自己实现碰撞检测时用 Physics.Raycast 或 SphereCast 做线性扫描检测。Day 2 阶段用第一种方案就够了后面做高速模式时再引入第二第三种方案。9. 缓存、对象池与性能优化建议上面的代码在功能上是完整的但离“线上可运行”还有一段距离。这里提前给出几个 Day 2 阶段就要记住的优化原则避免项目中期再重构。第一障碍物和金币必须使用对象池而不是 Instantiate 后立即 Destroy。Instantiate和Destroy会产生堆内存峰值在手机端轻则卡顿掉帧重则 Direct Memory 溢出导致闪退。跑酷游戏每秒钟可能生成几个障碍物、十几个金币如果不做对象池游戏运行 10 分钟后场景对象的创建和销毁量会非常恐怖。实现对象池的最小方案// 文件路径Assets/Scripts/Core/PoolManager.cs using System.Collections.Generic; using UnityEngine; public class PoolManager : MonoBehaviour { public static PoolManager Instance; private Dictionarystring, QueueGameObject poolDic new Dictionarystring, QueueGameObject(); private void Awake() { Instance this; } public GameObject Get(string key, GameObject prefab, Vector3 pos, Quaternion rot) { GameObject go null; if (poolDic.ContainsKey(key) poolDic[key].Count 0) { go poolDic[key].Dequeue(); } else { go Instantiate(prefab); } go.transform.SetPositionAndRotation(pos, rot); go.SetActive(true); return go; } public void Return(string key, GameObject go) { go.SetActive(false); if (!poolDic.ContainsKey(key)) { poolDic[key] new QueueGameObject(); } poolDic[key].Enqueue(go); } }使用对象池的收益在长局游戏中非常明显。假设一场游戏跑 5 分钟不做对象池时可能要实例化几千个对象。用对象池后活跃对象数量只需要保持在一个可控范围内内存曲线会非常平坦。第二跑道贴图和材质尽量用图集打包。跑酷游戏的跑道、背景、障碍物、金币如果使用大量独立贴图Draw Call 会直线上升手机端发热严重。合理做法是把一局游戏中出现的所有 UI 和场景元素打包到同一个图集配合Texture Atlas和Sprite Atlas使用。3D 模型尽量使用共享材质减少材质实例的数量。第三分帧处理对象生成。当进入新难度关卡或新场景段落时一次性生成大量障碍物和金币会引起瞬间卡顿。解决方式是把生成操作分散到多帧执行例如每帧最多生成 3 个对象其余的排队等待。这在跑酷游戏里体现为“远方的障碍物是逐渐出现而不是瞬间冒出来的”玩家并不会察觉异常但是性能体验提升非常大。10. 最佳实践与工程建议10.1 用 ScriptableObject 管理关卡难度跑酷游戏的地图难度曲线不能用硬编码的数字写在代码里推荐使用 ScriptableObject 来自定义难度配置。这样策划同学可以不改代码就调整障碍物密度、金币数量、速度增长曲线。// 文件路径Assets/Scripts/Settings/DifficultySettings.cs using UnityEngine; [CreateAssetMenu(fileName DifficultySettings, menuName Runner/Difficulty Settings)] public class DifficultySettings : ScriptableObject { public float startSpeed 10f; public float maxSpeed 25f; public float speedIncreaseRate 0.15f; public float minSpawnInterval 4f; public float maxSpawnInterval 10f; public int coinGroupMin 1; public int coinGroupMax 5; }把速度增长、生成间隔全部参数化后游戏平衡性调配会高效很多。速度不是直线增加的更推荐阶梯式增长每过 30 秒速度提升一个档位让玩家在阶段内获得“我能掌控局面”的安全感阶段切换时再感受到挑战升级。10.2 日志与错误跟踪移动端游戏出现 bug 时最困难的事情是看不到日志。Day 2 阶段就应该考虑接入日志工具比如 Unity 的Debug.unityLogger配合Application.logMessageReceived事件把关键日志写入本地文件。这样玩家反馈崩溃问题时至少能拿到玩家设备上的错误堆栈。无论接入什么工具核心原则是打日志要有目的性不去打印冗余信息。跳帧、碰撞判定失败、对象池为空这三种情况是跑酷游戏排查的首选日志点。10.3 让“看似完整”的 Demo 保持可扩展Day 2 写代码时不要急着把美术资源全部导入。先把所有模块的接口和逻辑定义清楚用最简陋的 Capsule 代替角色用 Cube 代替障碍物。只要框架是稳定的后面放美术资源只是一个挂载替换的过程。反过来如果先调整美术资源和动画框架有缺陷时改动成本会高很多。一个值得养成的习惯是每天开发结束后花 10 分钟清点代码里的临时 TODO 和 Debug.Log把还没完成的功能标记出来。跑酷游戏开发周期短很容易陷入“先把功能堆出来”的心态结果代码里堆满了游戏逻辑和调试代码的混合产物后期改造非常痛苦。11. 总结与后续方向这一天的开发重点并不在于跑通了多少功能而在于把跑酷游戏最核心的“三角柱”立住了Player 的操控手感、跑道/障碍物生成的稳定性、计分与碰撞的可扩展性。这几个模块如果从一开始就有清晰的边界后续加入新内容时会发现接入成本非常低。如果你正在实际开发跑酷游戏下一步建议按照下面的顺序继续推进先把玩家碰撞体与障碍物碰撞体的尺寸、位置用可视化 Gizmos 画出来逐个检查是否与美术表现一致。然后接对象池替换现有的Instantiate/Destroy逻辑并用 Profiler 对比替换前后的性能曲线。再实现游戏状态管理Ready/Playing/Pause/GameOver把所有 UI 弹窗接入状态机避免后面 UI 逻辑把场景脚本搅乱。最后才去细化美术效果、动画过渡和音效反馈。跑酷游戏这个品类看着小但它对代码纪律性的要求一点也不低。它的代码量不大所以每一个决策都值得深思熟虑。如果基础框架是乱的再小的改动都可能引发连锁问题如果基础框架清晰后面的功能开发反而会充满乐趣。对于 Day 3比较推荐的切入点是 Game Flow 状态机、暂停/复活机制以及广告 SDK 的接入预留。广告和复活是休闲游戏商业化的关键入口但它们的实现必须建立在稳定的状态管理之上。如果直接在现有代码上临时加复活逻辑大概率会引入状态混乱的 bug。Day 2 的状态骨架打好后Day 3 的重点就非常明确了把“角色死亡”这件事从单一的动画播放升级成完整的状态流转流程。跑酷游戏的魅力在于它的纯粹一条路、一个角色、无数个“再来一次”。越是简单的核心玩法越考验底层代码的素质。希望这篇文章能帮你在第二天就把地基打牢接下来的路会越走越顺。 跑酷游戏开发Day2：Unity核心框架与角色控制实现
如果你正打算做一款休闲跑酷游戏或者已经尝试过跑酷品类开发却始终觉得“手感差一点”“细节不到位”那么这篇文章值得你停下来看完。它记录的并不是什么高深莫测的游戏架构而是一个跑酷项目第二天的开发进度场景框架搭到什么程度角色控制怎么做才能更跟手障碍物和跑道的生成该怎么组织。跑酷游戏看着简单真正动手写起来你会发现入口处全是细节问题。入局跑酷游戏的门槛不高跑通一个Demo可能只需要一个晚上。但如果你只看过几个教程就自己上手大概率会遇到这样几个问题角色跳跃高度飘忽不定、跑道延伸不连贯、碰撞判定时灵时不灵、手机端的操作响应延迟明显。这些问题如果放到项目中期再去修会非常痛苦。Day 2 要做的就是把最容易被忽略的核心框架定好Player 控制、跑道生成、碰撞与计分。这三块搭稳了后面加入道具、皮肤、无尽模式、广告变现都只是时间问题。本文会从跑酷游戏最底层的原理讲起拆解一个可供复用的 Unity 实现方案包含完整可跑的代码示例和常见问题排查。无论你是第一次做跑酷游戏还是正处于项目重构阶段这篇文章的核心判断是一致的跑酷游戏的竞争力从来不在玩法创意而在于基础框架的稳定性和角色的操控手感。1. 跑酷游戏到底难在哪里跑酷这类休闲游戏在需求文档里往往只写三件事角色往前跑、玩家控制跳跃和滑铲、躲避障碍物获取金币。需求看着简单但把它翻译成技术方案时很多新手会踩进同一个坑把所有逻辑塞进一个 Player 脚本里场景和障碍物全部靠美术手摆碰撞体尺寸随意设置结果就是Demo能玩、上线后体验稀碎。跑酷类游戏的技术难点实际上集中在四个方面第一角色移动方式的选择。跑酷游戏通常不使用真正的物理引擎来驱动角色前进而是让世界跑道、障碍物、装饰物向玩家移动角色本身在原地做跑动动画。这样做的好处很明显角色速度计算更稳定、碰撞判定更容易控制、对不同性能手机更友好。真实物理移动会让角色受到撞击力、摩擦力等不确定因素干扰这对追求“确定性手感”的跑酷游戏来说是致命的。第二控制响应的及时性。玩家点击屏幕的瞬间要完成跳跃或滑铲如果响应延迟超过一两帧玩家的直觉就会被打破。这个问题的根源往往不在代码速度而在于动画切换的过渡、状态机的设计以及输入读取的时机。第三障碍物排列的逻辑。如果障碍物是纯随机生成的很容易出现连续三个跳跃障碍或者跳跃后紧接着滑铲死角这样的“死局”玩家会认为游戏不公平。跑酷游戏的随机难度一定是有约束的随机。第四碰撞框的精度。玩家看到的角色模型是一回事碰撞盒又是另一回事。碰撞盒太大玩家明明躲过了却判定撞上碰撞盒太小看起来撞上却还能跑。如何调节碰撞盒大小和玩家感知之间的关系是跑酷手感的核心秘密之一。所以Day 2 的开发目标不是写一堆功能点而是把上述四件事的框架搭好。2. 跑酷游戏的核心架构设计跑酷类游戏的代码架构并不复杂市面上大多数同类产品都可以抽象为三个模块Player 模块负责角色状态机、跳跃、滑铲、下落、转向、动画切换和碰撞回调。Track 模块负责跑道的无限延伸、场景碎片的循环利用、障碍物和金币的生成与回收。Game Flow 模块负责游戏状态切换、得分计算、暂停/恢复、Game Over 处理以及UI事件。很多新手会忽略第三层把得分、UI、游戏状态都直接写在 Player 里。Demo 阶段看不出问题一旦接入广告、分享、排行榜、复活机制Player 脚本会膨胀到一个几千行的“上帝类”改一行动画逻辑都可能影响计分。推荐的项目目录结构如下Assets/ ├── Scenes/ // 场景文件 │ └── MainGame.unity ├── Scripts/ │ ├── Core/ // 游戏状态机、事件中心 │ ├── Player/ // 角色控制、动画、碰撞 │ ├── Track/ // 跑道生成、障碍物生成 │ └── UI/ // 计分、暂停、结算 ├── Prefabs/ │ ├── Player/ │ ├── TrackParts/ // 跑道块 │ └── Obstacles/ // 障碍物 ├── Art/ // 美术资源 └── Settings/ // 配置数据核心原则只有一条把角色、赛道、游戏流程三者解耦。角色不需要知道分数怎么算赛道不需要知道角色当前在哪个状态游戏流程只需要监听各模块的事件。这样后续每个独立模块都能单独替换和测试。3. 环境准备与前置条件本次开发基于 Unity 2021.3 LTS长期支持版本这个版本在移动端跑酷类游戏的开发上足够稳定Android 和 iOS 构建工具链都比较成熟。如果你使用的是更高版本本文涉及的核心 API 没有大的变化思路依然通用。如果在实际项目中用的是不同版本请以你项目实际版本为准这里重点演示的是通用实现思路。开发前需要确认以下几点操作系统Windows 10/11 或 macOS 均可。Unity Hub建议通过 Unity Hub 管理 2021.3 LTS 版本。构建目标Android 或 iOS需要提前安装对应的构建模块。版本控制工具Git以及 LFS大文件存储用于管理美术和音频资源。创建一个名为 TomCatRunner 的项目模板选择 3D Core。为什么要选 3D 而不是 2D跑酷类游戏的表现形式虽然看起来是“平面往前跑”但角色模型、障碍物深度、金币旋转等元素在 3D 空间中实现更自然相机跟随也更容易调整。后面如果想要 2.5D 的视觉效果直接在 3D 场景中调整相机角度即可。项目创建完成后建议立即调整几个关键设置第一步设置输入机制。跑酷游戏的输入主要依赖触屏或鼠标不需要重力感应。打开Edit Project Settings Player Android/iOS设置确认输入处理方式为Input System (Old)或Input Manager本次示例使用旧版 Input Manager因为它最简单、最容易理解。如果你用的是新版 Input System需要注意InputAction的配置方式。第二步固定帧率。跑酷游戏对帧稳定性要求很高打开Edit Project Settings Quality在Other选项里可以关闭阴影或调整阴影质量。实际项目里更推荐在代码中设置目标帧率// 文件路径Assets/Scripts/Core/GameSettings.cs using UnityEngine; public class GameSettings : MonoBehaviour { private void Awake() { // 手机端目标帧率设为 60不要依赖默认值 Application.targetFrameRate 60; // 关闭垂直同步避免部分安卓设备强制锁 30 帧 QualitySettings.vSyncCount 0; } }这里的核心原因是跑酷游戏的碰撞和位移计算依赖Time.deltaTime如果帧率忽高忽低角色跳跃的弧线、障碍物接近的速度都会时快时慢玩家会感觉“手感很不稳”。锁帧能较大程度缓解这个问题但设备性能不足时仍需配合对角色碰撞的处理来兜底。4. 场景搭建与跑道生成逻辑跑酷游戏的地图不需要美术摆一整条赛道而是由多个跑道块拼接而成。每个跑道块是一个 Prefab长度固定内部包含地面、装饰物、可能的障碍物生成点。当角色向前“跑动”时检测到即将走完当前跑道块就生成下一段跑道块并回收身后的跑道块。这个概念称为“对象池 预制体拼接”是跑酷游戏里最成熟的地图加载方式。4.1 跑道块构成新建跑道块 Prefab命名为Track_Base结构如下Track_Base ├── Ground // 带 BoxCollider 的地面 ├── LeftBound // 左侧边界隐形墙体用于防止角色跑出地图 ├── RightBound // 右侧边界同理 └── Decorations // 装饰物容器树木、路牌可放多个子物体跑道块长度建议设置为固定值比如30f。这个长度后面会被生成器用到。地下的 Ground 只需要一层薄的 BoxCollider碰撞体越多物理计算就越浪费。装饰物不要挂碰撞体宁可让玩家的视线穿过它也不要让不必要的碰撞参与计算。4.2 跑道生成器跑道生成器的核心职责就是维护一个“当前活动跑道块”的队列。它不断生成新块、移除旧块同时把障碍物生成的任务交给障碍物生成器。// 文件路径Assets/Scripts/Track/TrackSpawner.cs using System.Collections.Generic; using UnityEngine; public class TrackSpawner : MonoBehaviour { [Header(跑道块预制体)] public GameObject trackPrefab; [Header(每次生成的跑道块数量)] public int poolSize 5; [Header(跑道块长度需与预制体长度一致)] public float trackLength 30f; private ListGameObject activeTracks new ListGameObject(); private float spawnZ 0f; private void Start() { // 启动时先生成 poolSize 段跑道保证开局不穿帮 for (int i 0; i poolSize; i) { SpawnTrack(); } } private void Update() { // 当最后一段跑道快被走完时补充新跑道 // 用角色 z 坐标与跑道总长的差值作为判定条件 } private void SpawnTrack() { GameObject track Instantiate(trackPrefab, transform); track.transform.position new Vector3(0f, 0f, spawnZ); spawnZ trackLength; activeTracks.Add(track); // 如果当前跑道数量超出保持值移除最早的一段 if (activeTracks.Count poolSize) { RemoveFirstTrack(); } } private void RemoveFirstTrack() { GameObject old activeTracks[0]; activeTracks.RemoveAt(0); Destroy(old.gameObject); } }这样实现的优点是无论游戏运行多久场景中存活的跑道块数量始终不超过poolSize1内存占用非常稳定。Destroy在频繁调用时会产生性能压力实际工程项目可以换成对象池回收机制这是 Day 4 之后要考虑的优化点。4.3 障碍物生成策略障碍物不能直接挂在跑道块上由美术摆设那样会让每一局的路线完全一致。更合理的方案是跑道块提供一个“播种接口”由障碍物生成器在跑道块被激活时根据当前难度等级和一条有约束的随机规则把障碍物摆进去。先看一个最简单的实现// 文件路径Assets/Scripts/Track/ObstacleSpawner.cs using UnityEngine; public class ObstacleSpawner : MonoBehaviour { [Header(障碍物预制体)] public GameObject lowObstacle; // 需要跳跃的矮障碍 public GameObject highObstacle; // 需要滑铲的高障碍 [Header(生成范围)] public float minDistance 5f; public float maxDistance 12f; private float nextSpawnZ 10f; private int lastPatternIndex -1; public void SpawnObstacle(float startZ, float trackZLength) { while (nextSpawnZ startZ trackZLength) { // 随机选择障碍类型0 需要跳跃1 需要滑铲 int patternIndex Random.Range(0, 2); // 避免连续出现同类型导致玩家操作疲劳 if (patternIndex lastPatternIndex) { patternIndex (patternIndex 1) % 2; } lastPatternIndex patternIndex; GameObject obstacle PickObstacle(patternIndex); PlaceObstacle(obstacle, nextSpawnZ); nextSpawnZ Random.Range(minDistance, maxDistance); } } private GameObject PickObstacle(int index) { return index 0 ? lowObstacle : highObstacle; } private void PlaceObstacle(GameObject obstacle, float z) { GameObject go Instantiate(obstacle); go.transform.position new Vector3(0f, 0f, z); } }这里的约束规则很关键连续不会出现两次同类型的障碍物。这个规则就是跑酷游戏“公平性”的底层实现。玩家跳过矮障碍后下一段大概率是滑铲这样给出手指的切换留出了反应时间。障碍物生成时还需要考虑“死局”问题。比如跳跃障碍后紧接着立刻出现上压障碍玩家落地瞬间根本来不及反应。因此生成障碍物时还要引入一个“安全距离”的概念——当上一个障碍物距离当前生成位置过近时跳过这次生成直到距离放宽。5. 玩家控制核心代码实现玩家控制是跑酷游戏最核心的部分。这一节会给出一个可运行的基础版 PlayerController 框架包含状态机、跳跃物理、滑铲和碰撞回调。代码力求精简方便读者理解核心逻辑。5.1 角色基础状态与垂直移动跑酷游戏中的“跳跃”其实是数学抛物线不依赖 Unity 物理引擎的刚体。这样做的好处是省略重力加速度、摩擦力等物理因素的干扰跳跃高度和时间完全可控。// 文件路径Assets/Scripts/Player/PlayerController.cs using UnityEngine; public class PlayerController : MonoBehaviour { [Header(移动参数)] public float jumpHeight 5f; public float jumpDuration 0.5f; public float slideDuration 0.8f; public float horizontalSpeed 8f; [Header(状态检测)] public Transform groundCheck; public LayerMask groundLayer; private enum PlayerState { Running, Jumping, Sliding, Dead } private PlayerState state PlayerState.Running; private CharacterController controller; private float verticalVelocity 0f; private float stateTimer 0f; private float currentTrackZ 0f; private void Awake() { controller GetComponentCharacterController(); } private void Update() { if (state PlayerState.Dead || state PlayerState.Sliding) { return; } HandleInput(); ApplyVerticalMovement(); } private void HandleInput() { if (Input.GetButtonDown(Jump) state PlayerState.Running) { state PlayerState.Jumping; stateTimer jumpDuration; // 跳跃初速度根据目标高度计算 verticalVelocity (2f * jumpHeight) / jumpDuration; } else if (Input.GetButtonDown(Fire1) state PlayerState.Running) { StartSlide(); } else if (Input.GetButtonDown(Jump) state PlayerState.Jumping) { // 空中再次点击可加速下落增强操作感 stateTimer 0f; verticalVelocity -4f; } } private void ApplyVerticalMovement() { if (state PlayerState.Jumping) { stateTimer - Time.deltaTime; verticalVelocity - (2f * jumpHeight) / (jumpDuration * jumpDuration) * Time.deltaTime; if (stateTimer 0f) { verticalVelocity 0f; state PlayerState.Running; stateTimer 0f; } } else if (state PlayerState.Running) { verticalVelocity IsGrounded() ? -2f : -9.8f * Time.deltaTime; } // 应用垂直位移 Vector3 move new Vector3(0f, verticalVelocity, 0f) * Time.deltaTime; controller.Move(move); } private bool IsGrounded() { return Physics.CheckSphere(groundCheck.position, 0.1f, groundLayer); } private void StartSlide() { state PlayerState.Sliding; stateTimer slideDuration; // 滑铲时降低碰撞体高度后续可通过动画配合缩放 Vector3 center controller.center; center.y 0.5f; controller.center center; controller.height 1f; Invoke(nameof(EndSlide), slideDuration); } private void EndSlide() { state PlayerState.Running; Vector3 center controller.center; center.y 1f; controller.center center; controller.height 2f; } }这个版本的跳跃实现不需要 Rigidbody只用CharacterController 手动垂直速度。verticalVelocity相当于现实中跳跃速度在竖直方向的分量跳跃过程中它被一个恒定的减速项拉回地面。数学上等价于竖直上抛运动但代码里不涉及任何物理引擎的干扰因此跳跃轨迹极其稳定。空中二次点击加速下落是非常关键的手感细节。很多跑酷游戏让人觉得“飘”原因就是跳跃下落过程太长玩家明明感觉角色已经该落地了画面里却还在空中。加入快速下落机制后玩家对节奏的掌控感会显著提升。5.2 水平变道操作跑酷游戏通常有三条或五条跑道玩家通过左右滑动屏幕切换跑道并躲避障碍物。这个功能的核心是水平方向的平滑移动而不是直接瞬移过去。直接瞬移看起来很不自然还会破坏玩家对角色位置的预判。// 文件路径Assets/Scripts/Player/PlayerController_Lane.cs // 该文件是 PlayerController 的部分类扩展需要声明为 partial class using UnityEngine; public partial class PlayerController : MonoBehaviour { public int currentLane 1; // 当前跑道0 / 1 / 2 public float laneWidth 2.5f; public float laneChangeSpeed 10f; private Vector3 targetLanePosition; private void HandleLaneInput() { if (Input.GetButtonDown(Horizontal)) { float x Input.GetAxisRaw(Horizontal); if (x 0 currentLane 0) { currentLane--; } else if (x 0 currentLane 2) { currentLane; } } // 在 Update 外部每帧调用确保移动平滑 Vector3 goal new Vector3((currentLane - 1) * laneWidth, transform.position.y, transform.position.z); transform.position Vector3.Lerp(transform.position, goal, laneChangeSpeed * Time.deltaTime); } }实现思路是玩家按下左/右键时改变目标跑道编号然后把当前位置向目标位置做线性插值。Lerp的系数带上帧率修正后无论设备帧率是高是低变道速度都保持一致。注意这里的横向移动不能直接修改CharacterController.Move的 y 分量否则会和跳跃计算冲突。更稳妥的做法是按需在 Update 中调用位置插值或者把横向移动也交给controller.Move统一处理。还需要注意一点变道过程中需要短暂屏蔽输入否则玩家疯狂按键时角色会在跑道之间高频抖动既影响画面也不利于碰撞判断。实际项目中可以引入一个变道冷却时间比如 0.15 秒内不允许连续变道。5.3 动画状态同步状态机的切换必须同步给 AnimatorAnimator 的参数建议使用触发器或布尔变量组合而不是枚举直接赋值。// PlayerController 内部补充 private Animator animator; private void Awake() { controller GetComponentCharacterController(); animator GetComponentInChildrenAnimator(); } private void UpdateAnimation() { switch (state) { case PlayerState.Running: animator.SetBool(Running, true); animator.SetBool(Jumping, false); animator.SetBool(Sliding, false); break; case PlayerState.Jumping: animator.SetBool(Running, false); animator.SetBool(Jumping, true); break; case PlayerState.Sliding: animator.SetBool(Running, false); animator.SetBool(Sliding, true); break; } }这里有一个常见的坑如果使用Animator.CrossFade直接播放动画频繁切换状态会造成动画过渡冲突。正确的做法是给动画状态机设置合理的过渡时间和过渡条件把跳跃、滑铲、跑动的过渡间隔都控制在 0.05 到 0.1 秒内让动画切换干脆利落。6. 计分系统与碰撞判定计分系统在很多跑酷教程里往往只是一句话带过但它实际上是“成就感”的核心来源。Day 2 阶段先实现一个简单可靠的计分框架跑动距离分和金币分。6.1 计分管理器// 文件路径Assets/Scripts/Core/ScoreManager.cs using UnityEngine; using UnityEngine.Events; public class ScoreManager : MonoBehaviour { public static ScoreManager Instance; public int CurrentScore { get; private set; } public int CurrentCoins { get; private set; } public float RunDistance { get; private set; } public UnityEventint onScoreChanged; public UnityEventint onCoinChanged; private void Awake() { if (Instance null) { Instance this; } else { Destroy(gameObject); } } private void Update() { if (!GameFlow.Instance.IsPlaying) return; float deltaDistance 10f * Time.deltaTime; RunDistance deltaDistance; AddScore((int)(deltaDistance * 10f)); } public void AddScore(int value) { CurrentScore value; onScoreChanged?.Invoke(CurrentScore); } public void AddCoin() { CurrentCoins; onCoinChanged?.Invoke(CurrentCoins); } }分数来源分两部分一部分是距离分持续累积另一部分是金币分获得时直接加上去。ScoreManager使用单例模式但通过事件而不是“其他脚本主动查分数”的方式来通知 UI这样 UI 层只需要监听事件不需要知道计分细节。6.2 碰撞判定跑酷游戏的碰撞判定要区分两类角色碰到障碍物游戏结束。角色碰到金币获得奖励。障碍物碰撞障碍物预制体应该挂一个Obstacle标签或脚本组件角色进入触发器时判断是否为障碍物。// 文件路径Assets/Scripts/Player/PlayerCollision.cs using UnityEngine; public class PlayerCollision : MonoBehaviour { private void OnTriggerEnter(Collider other) { if (other.CompareTag(Obstacle)) { // 通知 Player 进入死亡状态 GetComponentPlayerController().Die(); } else if (other.CompareTag(Coin)) { ScoreManager.Instance.AddCoin(); Destroy(other.gameObject); } } }因为使用了CharacterController碰撞事件会以OnTriggerEnter形式触发障碍物要挂在Trigger类型的 Collider 上。这个设计把碰撞职责从PlayerController中分离出来以后给角色加护盾、磁铁等道具时直接扩展碰撞脚本就行。这里有很重要的性能调优点不要给金币使用 MeshCollider一定要用 BoxCollider 或 SphereCollider并勾选Is Trigger。每个金币的碰撞检测范围不用精确贴合模型可以稍微大一点让玩家“擦边吸到金币”的感觉更明显这是提高游戏爽感的设计也是物理上的容错设计。利用碰撞高度差优化手感很多玩家抱怨“明明滑铲了还是撞上高障碍”原因往往是碰撞盒没有在滑铲时跟着动画同步变更。在 5.1 节的代码里我们已经处理了滑铲时controller.height和controller.center的变更但要注意把这次变更和 Animator 的动画播放同步。如果动画已经播到滑铲姿势但碰撞盒还没降下来就会出现“模型趴下了、碰撞体还站着”的穿帮效果。判断统一在动画事件里完成// 在 Animator 事件中调用 public void OnAnimationSlideStart() { SetColliderForSlide(); } public void OnAnimationSlideEnd() { SetColliderForRun(); }7. 运行结果与效果验证搭好上述框架后运行 Unity 场景你会看到角色持续向前移动跑道块依次铺开障碍物和金币按规则生成在路线上。按空格键执行跳跃按 Ctrl 或自定义按键执行滑铲左右方向键切换跑道。正常情况下的验证标准如下连续跑动 30 秒以上场景内 GameObject 数量保持相对稳定不会无限增长。跳跃最高点看起来在角色胸口位置不和头顶碰撞体高度冲突。障碍物连续出现时不存在两个同类型障碍紧贴的情况。金币盒子的触发范围略大于视觉大小玩家擦边也能吃到金币。撞到障碍物后角色停留在碰撞点而不是穿模后继续前进。如果验证中发现跳跃高度不正常第一步应该检查jumpHeight和目标帧率设置。跳跃高度的计算依赖Time.deltaTime如果手机端帧率低于 30跳跃的实际高度会比理想值偏小。更稳健的方案是把跳跃改为基于时间的速度积分彻底排除帧率波动的影响。8. 常见问题与排查思路问题现象可能原因排查方式解决方案跳跃高度忽高忽低帧率波动影响Time.deltaTime计算查看 Profiler 中的帧率曲线固定Application.targetFrameRate或改用基于时间的跳跃模型角色卡在障碍物边界使用CharacterController.Move时速度过快发生隧穿检查单帧最大位移量将最大移动速度限制在 20m/s 以内或对高速物体分段检测滑铲后碰撞体恢复异常Invoke被多次触发状态没同步打印状态日志检查StartSlide是否被重复调用在Update中统一基于stateTimer做状态切换不使用Invoke跑道块之间出现裂缝跑道块长度配置和生成间距不一致打印生成位置和预制体长度统一读取预制体长度而不是手动填写trackLength金币无法触发判定OnTriggerEnter没有调用检查角色是否挂了CharacterController检测金币是否挂了Trigger Collider角色必须挂CharacterController才能触发触发器事件障碍物连续出现同类型随机规则没生效打印生成日志实现“上一次类型”检测同类型时强制切换这里重点解释一下最容易忽略的“隧道效应”问题。CharacterController.Move在移动距离过大时可能会直接穿过薄碰撞体导致角色明明在视觉上撞到了障碍物却被判定为通过。这个问题在高速跑酷场景中非常常见因为在游戏后期角色速度越来越快单帧位移量会不断增大。解决思路有三个层次第一限制最大速度让单帧位移不要超过最小碰撞体厚度的两倍第二把障碍物碰撞体做成多个小盒子的组合而不是一个很薄的单片第三在自己实现碰撞检测时用 Physics.Raycast 或 SphereCast 做线性扫描检测。Day 2 阶段用第一种方案就够了后面做高速模式时再引入第二第三种方案。9. 缓存、对象池与性能优化建议上面的代码在功能上是完整的但离“线上可运行”还有一段距离。这里提前给出几个 Day 2 阶段就要记住的优化原则避免项目中期再重构。第一障碍物和金币必须使用对象池而不是 Instantiate 后立即 Destroy。Instantiate和Destroy会产生堆内存峰值在手机端轻则卡顿掉帧重则 Direct Memory 溢出导致闪退。跑酷游戏每秒钟可能生成几个障碍物、十几个金币如果不做对象池游戏运行 10 分钟后场景对象的创建和销毁量会非常恐怖。实现对象池的最小方案// 文件路径Assets/Scripts/Core/PoolManager.cs using System.Collections.Generic; using UnityEngine; public class PoolManager : MonoBehaviour { public static PoolManager Instance; private Dictionarystring, QueueGameObject poolDic new Dictionarystring, QueueGameObject(); private void Awake() { Instance this; } public GameObject Get(string key, GameObject prefab, Vector3 pos, Quaternion rot) { GameObject go null; if (poolDic.ContainsKey(key) poolDic[key].Count 0) { go poolDic[key].Dequeue(); } else { go Instantiate(prefab); } go.transform.SetPositionAndRotation(pos, rot); go.SetActive(true); return go; } public void Return(string key, GameObject go) { go.SetActive(false); if (!poolDic.ContainsKey(key)) { poolDic[key] new QueueGameObject(); } poolDic[key].Enqueue(go); } }使用对象池的收益在长局游戏中非常明显。假设一场游戏跑 5 分钟不做对象池时可能要实例化几千个对象。用对象池后活跃对象数量只需要保持在一个可控范围内内存曲线会非常平坦。第二跑道贴图和材质尽量用图集打包。跑酷游戏的跑道、背景、障碍物、金币如果使用大量独立贴图Draw Call 会直线上升手机端发热严重。合理做法是把一局游戏中出现的所有 UI 和场景元素打包到同一个图集配合Texture Atlas和Sprite Atlas使用。3D 模型尽量使用共享材质减少材质实例的数量。第三分帧处理对象生成。当进入新难度关卡或新场景段落时一次性生成大量障碍物和金币会引起瞬间卡顿。解决方式是把生成操作分散到多帧执行例如每帧最多生成 3 个对象其余的排队等待。这在跑酷游戏里体现为“远方的障碍物是逐渐出现而不是瞬间冒出来的”玩家并不会察觉异常但是性能体验提升非常大。10. 最佳实践与工程建议10.1 用 ScriptableObject 管理关卡难度跑酷游戏的地图难度曲线不能用硬编码的数字写在代码里推荐使用 ScriptableObject 来自定义难度配置。这样策划同学可以不改代码就调整障碍物密度、金币数量、速度增长曲线。// 文件路径Assets/Scripts/Settings/DifficultySettings.cs using UnityEngine; [CreateAssetMenu(fileName DifficultySettings, menuName Runner/Difficulty Settings)] public class DifficultySettings : ScriptableObject { public float startSpeed 10f; public float maxSpeed 25f; public float speedIncreaseRate 0.15f; public float minSpawnInterval 4f; public float maxSpawnInterval 10f; public int coinGroupMin 1; public int coinGroupMax 5; }把速度增长、生成间隔全部参数化后游戏平衡性调配会高效很多。速度不是直线增加的更推荐阶梯式增长每过 30 秒速度提升一个档位让玩家在阶段内获得“我能掌控局面”的安全感阶段切换时再感受到挑战升级。10.2 日志与错误跟踪移动端游戏出现 bug 时最困难的事情是看不到日志。Day 2 阶段就应该考虑接入日志工具比如 Unity 的Debug.unityLogger配合Application.logMessageReceived事件把关键日志写入本地文件。这样玩家反馈崩溃问题时至少能拿到玩家设备上的错误堆栈。无论接入什么工具核心原则是打日志要有目的性不去打印冗余信息。跳帧、碰撞判定失败、对象池为空这三种情况是跑酷游戏排查的首选日志点。10.3 让“看似完整”的 Demo 保持可扩展Day 2 写代码时不要急着把美术资源全部导入。先把所有模块的接口和逻辑定义清楚用最简陋的 Capsule 代替角色用 Cube 代替障碍物。只要框架是稳定的后面放美术资源只是一个挂载替换的过程。反过来如果先调整美术资源和动画框架有缺陷时改动成本会高很多。一个值得养成的习惯是每天开发结束后花 10 分钟清点代码里的临时 TODO 和 Debug.Log把还没完成的功能标记出来。跑酷游戏开发周期短很容易陷入“先把功能堆出来”的心态结果代码里堆满了游戏逻辑和调试代码的混合产物后期改造非常痛苦。11. 总结与后续方向这一天的开发重点并不在于跑通了多少功能而在于把跑酷游戏最核心的“三角柱”立住了Player 的操控手感、跑道/障碍物生成的稳定性、计分与碰撞的可扩展性。这几个模块如果从一开始就有清晰的边界后续加入新内容时会发现接入成本非常低。如果你正在实际开发跑酷游戏下一步建议按照下面的顺序继续推进先把玩家碰撞体与障碍物碰撞体的尺寸、位置用可视化 Gizmos 画出来逐个检查是否与美术表现一致。然后接对象池替换现有的Instantiate/Destroy逻辑并用 Profiler 对比替换前后的性能曲线。再实现游戏状态管理Ready/Playing/Pause/GameOver把所有 UI 弹窗接入状态机避免后面 UI 逻辑把场景脚本搅乱。最后才去细化美术效果、动画过渡和音效反馈。跑酷游戏这个品类看着小但它对代码纪律性的要求一点也不低。它的代码量不大所以每一个决策都值得深思熟虑。如果基础框架是乱的再小的改动都可能引发连锁问题如果基础框架清晰后面的功能开发反而会充满乐趣。对于 Day 3比较推荐的切入点是 Game Flow 状态机、暂停/复活机制以及广告 SDK 的接入预留。广告和复活是休闲游戏商业化的关键入口但它们的实现必须建立在稳定的状态管理之上。如果直接在现有代码上临时加复活逻辑大概率会引入状态混乱的 bug。Day 2 的状态骨架打好后Day 3 的重点就非常明确了把“角色死亡”这件事从单一的动画播放升级成完整的状态流转流程。跑酷游戏的魅力在于它的纯粹一条路、一个角色、无数个“再来一次”。越是简单的核心玩法越考验底层代码的素质。希望这篇文章能帮你在第二天就把地基打牢接下来的路会越走越顺。