企业官网建设流程全解析

3D滚球跑酷这个题材，几乎是每个Unity新手绕不开的"第一课"。原因很实在：它把物理系统、输入控制、相机跟随、碰撞检测、UI反馈这几块最核心的引擎能力全串了一遍，但又不至于像RPG那样一上来就被状态机和存档系统劝退。我自己带过不少刚接触Unity的朋友，十有八九第一个能跑起来的完整Demo就是滚球。这篇内容就是把这个过程完整拆开，从场景搭建到脚本落地，把每一步为什么这么做讲清楚，让你不只是照着抄，而是真能理解背后的逻辑，后面自己改需求、加玩法的时候不至于卡壳。

适合谁看？完全没碰过Unity的可以跟着走一遍建立整体认知；摸过一点但脚本写得磕磕绊绊的，可以重点看脚本结构和物理参数那几节；已经做过滚球但想搞清楚"为什么球会抖""为什么相机跟得别扭"的，直接跳到问题排查部分。全文基于Unity的通用实践展开，不绑定特定版本，2021 LTS之后的版本基本都能对上。

1. 项目整体设计与技术选型思路

1.1 为什么滚球是入门3D的最佳载体

先说说选型这件事。3D游戏入门题材很多，射击、平台跳跃、赛车都能做，但滚球有个天然优势：物理表现是"免费"的。Unity内置的PhysX物理引擎本身就处理刚体、重力、摩擦、碰撞，你不需要自己写运动学公式，给球挂个Rigidbody，加个力，它自己就滚起来了。这意味着新手可以把精力集中在"逻辑怎么组织"上，而不是被数学劝退。

另一个好处是反馈闭环短。球滚起来、撞到东西、掉下去、吃到收集物，这些事件的视觉和音效反馈都很直接，你改一行代码马上能看到效果，学习正反馈来得快。相比之下，做RPG你可能写半天对话系统还看不到画面变化，很容易失去耐心。

从技术覆盖面看，滚球项目能自然带出这些知识点：刚体物理与力的施加、碰撞与触发器、输入系统、相机跟随与插值、UI计数与状态显示、场景重载。这些是后面做任何3D项目都要反复用到的地基。所以它不是"玩具项目"，而是一个浓缩的核心能力训练场。

1.2 整体架构拆解：四个核心模块

我把这个项目拆成四块，每块职责单一，方便你理解和后续扩展：

这种拆法的核心思想是关注点分离。玩家控制脚本只管"怎么动"，不去管"吃到东西加几分"；计分逻辑放在GameManager里，收集物被触发时通知它就行。很多新手容易把所有逻辑塞进一个脚本，前期看着省事，等要加功能时就会发现牵一发动全身。哪怕项目小，也建议一开始就养成分模块的习惯。

1.3 物理驱动 vs 直接改位置的取舍

这里有个关键决策要提前说清楚：玩家移动到底用物理力还是直接改Transform位置？

直接改位置（transform.position += ...）写起来简单，但会绕过物理引擎，导致球撞墙时穿模、和别的刚体交互异常、摩擦力失效。而用Rigidbody.AddForce()让物理引擎接管，球会真实地滚动、碰撞、减速，手感自然得多。

代价是物理驱动需要调参——力给大了球飞出去，给小了推不动，摩擦和阻力设置不当球会一直滑。但这个调参过程恰恰是理解物理引擎的好机会。我的建议是：移动用物理力，转向和相机用插值，各取所长。下面实操部分会给出具体参数和调整思路。

2. 场景搭建与核心组件配置

2.1 场景基础搭建：地面、球、相机三件套

打开Unity新建一个3D项目，先做最基础的三样东西。

地面：右键Hierarchy → 3D Object → Plane，缩放调到(2,1,2)左右，这样有个40x40米的活动范围。给它换个材质颜色方便观察，或者直接用一个带纹理的Material。地面不需要挂Rigidbody，它作为静态碰撞体存在就行。

玩家球：3D Object → Sphere，位置放到地面上方一点，比如Y=1。关键一步是给它Add Component → Rigidbody。Rigidbody是物理系统的入口，没有它球就只是个静态模型。挂上之后注意检查Mass（质量）默认是1，先不动；Drag（阻力）和Angular Drag（角阻力）默认0.05和0.05，这两个参数后面要重点调。

相机：Main Camera默认存在，把它摆到球的后上方，比如位置(0, 5, -8)，朝向球。这个初始位置只是起点，后面会用脚本让它自动跟随。

注意：球和地面的碰撞体是自动带的（Sphere Collider和Mesh Collider），不要手动删掉。新手有时为了"干净"把Collider移除，结果球直接穿过地面掉进虚空，排查半天。

2.2 材质与视觉区分：让场景可读

一个纯灰的场景玩起来毫无反馈感。花五分钟做视觉区分很值得：

• 地面用深色或带网格纹理的材质，方便感知移动速度
• 玩家球用亮色（比如橙红），一眼能找到
• 收集物用金黄色，带点自发光（Emission）
• 障碍/危险区域用红色

创建材质的方式：Project窗口右键 → Create → Material，调Albedo颜色，拖到物体上。自发光在Material的Emission勾选后调颜色和强度。这些不影响逻辑，但直接影响你调试时能不能快速看清发生了什么，别省这一步。

2.3 刚体参数详解：Mass、Drag、Angular Drag怎么定

这三个参数是滚球手感的核心，值得单独讲。

Mass（质量）：默认1就行。质量影响的是碰撞时的动量传递，滚球项目里没有复杂的物体推挤，保持默认最省心。有人觉得"球轻一点好推"，把质量调到0.1，结果球撞到障碍物时被弹飞，反而难控制。

Drag（线性阻力）：控制球在不受力时减速的快慢。默认0.05几乎等于没有阻力，球会一直滑。滚球项目我一般设在0.5到1之间。设太高球像在泥里，设太低停不下来。可以先设0.8试手感。

Angular Drag（角阻力）：控制旋转衰减。这个参数很多人忽略，但它影响球"滚"的观感。设太低球会一直自转，设太高滚动感变木。建议0.5左右起步。

调参的方法论是：先给一组中间值，然后只改一个参数观察变化，别一次改三个，否则你根本不知道是哪个起了作用。这是调试物理的通用原则。

2.4 碰撞与触发器：Is Trigger的正确用法

收集物和终点区域这类"碰到就触发但不产生物理碰撞"的东西，要用触发器（Trigger）。做法是给物体挂Collider，勾选Is Trigger。勾选后物体不再阻挡运动，只会在进入/离开时发事件。

这里有个高频坑：触发器要生效，两个物体中至少一个得有Rigidbody。玩家球有Rigidbody，所以收集物只挂Collider + Is Trigger就能被检测到。但如果收集物也想有物理表现（比如被球撞飞），那就得给它也加Rigidbody，同时不能勾Is Trigger。

判断标准很简单：要物理碰撞就用普通Collider，要"穿过但触发事件"就用Is Trigger。收集物、终点、加速带用后者；墙壁、障碍用前者。

3. 脚本编程：从输入到移动的完整实现

3.1 玩家控制脚本：力的施加与输入读取

新建脚本PlayerController，挂在玩家球上。核心逻辑是读输入、算方向、施加力。先看完整代码：

using UnityEngine; public class PlayerController : MonoBehaviour { public float moveForce = 10f; public float maxSpeed = 8f; private Rigidbody rb; void Start() { rb = GetComponent<Rigidbody>(); } void FixedUpdate() { float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 force = new Vector3(h, 0f, v) * moveForce; rb.AddForce(force); // 限制最大速度，防止无限加速 if (rb.velocity.magnitude > maxSpeed) { rb.velocity = rb.velocity.normalized * maxSpeed; } } }

几个关键点解释一下。

为什么用FixedUpdate而不是Update：物理相关的操作（AddForce、改velocity）必须放在FixedUpdate里，因为它按固定时间步长（默认0.02秒）执行，和物理引擎同步。放Update里会因为帧率波动导致施力不均匀，球动起来一顿一顿的。这是新手最常见的错误之一。

Input.GetAxis的返回值：Horizontal对应A/D或左右方向键，Vertical对应W/S或上下，返回值是-1到1的平滑值（有渐变，不是瞬间跳变），所以移动手感会比较顺。如果你想要瞬间响应，用GetAxisRaw，返回-1、0、1的整数。

速度限制的必要性：AddForce是持续累加的，不限制的话球会越滚越快直到失控。用velocity.magnitude判断当前速度，超了就归一化后乘最大速度，把速度"压"回上限。这个技巧在几乎所有物理移动里都用得上。

3.2 相机跟随脚本：平滑跟随的实现

相机跟随最忌讳硬绑定（直接把相机位置设成球的位置），那样画面会跟着球的每个微小抖动一起抖，看着晕。正确做法是插值跟随：

using UnityEngine; public class CameraFollow : MonoBehaviour { public Transform target; public Vector3 offset = new Vector3(0f, 5f, -8f); public float smoothSpeed = 5f; void LateUpdate() { Vector3 desiredPos = target.position + offset; transform.position = Vector3.Lerp(transform.position, desiredPos, smoothSpeed * Time.deltaTime); transform.LookAt(target); } }

为什么用LateUpdate：相机跟随要在玩家移动之后再更新，否则会出现"相机先动、球后动"的一帧延迟，画面会轻微抖动。LateUpdate在所有Update执行完后运行，正好合适。

Lerp的第三个参数：smoothSpeed * Time.deltaTime控制跟随的"黏性"。值越大跟得越紧，越小越飘。5左右是个不错的起点。注意这个参数不是线性的，调的时候小步试。

offset的设计：offset是相机相对球的固定偏移，球往哪走相机就跟到哪，保持同样的视角。如果你想要相机稍微"滞后"一点营造速度感，可以调低smoothSpeed；想要更贴身的第三人称感，就减小offset的Z值。

3.3 收集物与计分：触发器事件与GameManager

收集物脚本挂在每个收集物上，逻辑是"被玩家碰到就通知管理器加分并销毁自己"：

using UnityEngine; public class Collectible : MonoBehaviour { public int scoreValue = 1; void OnTriggerEnter(Collider other) { if (other.CompareTag("Player")) { GameManager.Instance.AddScore(scoreValue); Destroy(gameObject); } } }

注意OnTriggerEnter的参数是Collider，不是Collision。前者用于触发器，后者用于物理碰撞，别搞混。另外玩家球要记得打上"Player"标签（Inspector顶部Tag下拉选Player），否则CompareTag永远返回false，收集物碰了没反应——这是排查时第一个要检查的点。

GameManager用单例模式，方便全局访问：

using UnityEngine; using UnityEngine.UI; public class GameManager : MonoBehaviour { public static GameManager Instance; public Text scoreText; private int score = 0; void Awake() { if (Instance == null) Instance = this; else Destroy(gameObject); } public void AddScore(int amount) { score += amount; scoreText.text = "Score: " + score; } }

Awake里做单例初始化，保证全局只有一个GameManager。scoreText在Inspector里拖入UI的Text组件。这里用的是旧版UI（UnityEngine.UI），如果你用TextMeshPro，把类型换成TMP_Text即可，逻辑一样。

3.4 胜负判定与场景重载

掉出地图或碰到终点要判定胜负。掉出地图可以用一个大的触发器区域放在地面下方，玩家进入就重开：

using UnityEngine; using UnityEngine.SceneManagement; public class GameManager : MonoBehaviour { // ... 前面的代码 public void GameOver() { // 可以在这里显示失败UI，简单起见直接重载 SceneManager.LoadScene(SceneManager.GetActiveScene().buildIndex); } }

重载场景用SceneManager.LoadScene，传入当前场景的buildIndex。注意要在脚本顶部using UnityEngine.SceneManagement;。这个方式简单粗暴但有效，适合入门项目。进阶做法是做个失败面板，让玩家点按钮再重开，体验更好。

4. 实操全流程与参数调优实录

4.1 从零到可玩：完整搭建步骤

把前面零散的点串成一条完整流程，照着走一遍就能跑起来：

1. 新建3D项目，保存场景为"RollBall"
2. 创建Plane作地面，缩放(2,1,2)，赋深色材质
3. 创建Sphere作玩家，Y=1，Add Rigidbody，Tag设为Player，赋亮色材质
4. 创建CameraFollow脚本挂到Main Camera，target拖入玩家球
5. 创建PlayerController脚本挂到玩家球
6. 创建3-5个Cube或Sphere作收集物，勾选Collider的Is Trigger，挂Collectible脚本，赋金黄色材质
7. 创建空物体GameManager，挂GameManager脚本，创建UI Text并拖入scoreText
8. 在地面下方放一个大Box Collider勾Is Trigger，挂一个检测掉落的脚本调用GameOver
9. 运行测试，用WASD或方向键控制球移动

这套流程走完，一个最小可玩的滚球Demo就有了。别急着加花哨功能，先确保"能滚、能吃、能计分、能重开"这四件事都正常，再往上叠。

4.2 手感调优：三组参数对照实验

手感这东西很主观，但有几个方向可以试。我做过几组对照，记录如下：

我最终选的是B组附近微调。调参顺序建议：先定maxSpeed（决定整体节奏），再调moveForce（决定加速快慢），最后调Drag和Angular Drag（决定松手后的滑行感）。这个顺序是因为前两个决定"动起来"的观感，后两个决定"停下来"的观感，分开调不容易互相干扰。

4.3 加一点玩法：跳跃与加速带

基础版跑通后，加两个小机制能明显提升趣味性。

跳跃：在PlayerController里加一段，检测空格键且球接近地面时施加向上的力：

void FixedUpdate() { // ... 移动逻辑 if (Input.GetKeyDown(KeyCode.Space) && IsGrounded()) { rb.AddForce(Vector3.up * jumpForce, ForceMode.Impulse); } } bool IsGrounded() { return Physics.Raycast(transform.position, Vector3.down, 0.6f); }

ForceMode.Impulse表示瞬间施加冲量，适合跳跃这种一次性动作；默认的ForceMode.Force是持续力，适合移动。这个区别要分清。IsGrounded用射线检测球下方0.6米内有没有碰撞体，有就说明在地面上，防止空中连跳。

加速带：放一个触发器区域，玩家进入时临时提高maxSpeed或施加一个前向冲量，离开时恢复。这个机制能训练你对"状态临时改变"的处理，是后面做道具系统的基础。

4.4 常见问题与排查速查表

实际做的时候大概率会撞上这些坑，整理成表方便对照：

提示：排查物理问题时，打开Scene视图的Gizmos，能看到Collider的线框，很多时候"看不见的碰撞体"就是问题根源。

4.5 实操心得：几个文档里不会写的经验

做了几遍之后，有些体会是教程里不太提的。

第一，先做"丑但能跑"的版本。新手容易在材质、光照、后处理上花太多时间，结果核心逻辑还没通。我的习惯是先用默认材质把逻辑跑通，确认能玩，再回头美化。逻辑和美术分开推进，出问题时定位更快。

第二，善用Debug.Log但别滥用。在OnTriggerEnter里打一行日志确认触发是否发生，比盯着屏幕猜快得多。但记得发布前清理，大量日志会拖性能。

第三，物理参数改动要一次一个。前面提过，这里再强调，因为这是最容易犯的错。同时改Drag和moveForce，球手感变了你根本不知道是谁的功劳。

第四，场景重载前想清楚状态。用SceneManager重载会重置一切，包括分数。如果你的分数存在GameManager单例里且用了DontDestroyOnLoad，重载后分数会保留，可能不是你想要的。入门阶段建议直接重载、全部重置，逻辑最简单。

第五，给球加个拖尾或粒子。纯色球滚动时视觉上很难感知速度，加个Trail Renderer或简单的粒子，速度感立刻出来。这是性价比极高的体验优化。

5. 项目扩展方向与能力进阶路径

5.1 从Demo到完整小游戏的三个扩展点

基础版跑通后，往三个方向扩展能把它变成一个真正的小游戏。

关卡设计：用Cube搭出有高低差、有弯道的赛道，加移动平台、旋转障碍。这考验的是场景组织能力，建议用Prefab把重复元素（收集物、障碍）做成预制体，改一处全局生效。

计时与排行：加一个计时器，记录通关时间，配合PlayerPrefs存本地最佳成绩。PlayerPrefs是Unity自带的轻量存储，适合存分数、设置这类小数据，几行代码就能用。

多关卡切换：做2-3个场景，通关后加载下一关。这需要理解SceneManager的加载流程和场景索引管理，是迈向完整项目的必经一步。

5.2 这套能力能迁移到哪里

滚球项目练的这些能力，迁移性很强。物理移动和相机跟随是几乎所有3D游戏的基础；触发器事件是交互系统的核心；GameManager的单例模式是全局状态管理的入门范式。把这套东西吃透，再去做平台跳跃、赛车、甚至简单的第三人称动作游戏，你会发现很多逻辑是相通的，只是换了表现形式。

我个人觉得，滚球项目最大的价值不在于做出一个能玩的球，而在于让你建立起"输入→物理→反馈→状态"这条完整的思维链路。后面遇到任何新玩法，你都能往这个链路上套，知道该在哪一环加东西。

最后分享一个我常用的练习方法：每学一个新组件或新API，就回到这个滚球项目里试着用一下。比如学了协程，就用它做个倒计时；学了动画系统，就给球加个滚动动画。有一个熟悉的项目当试验田，学新东西会踏实很多，也不容易半途而废。