当前位置：首页 > news >正文

Unity弓箭抛物线弹道实现：手动物理积分与实时预览

news 2026/5/24 3:06:51

1. 为什么抛物线不是“画一条弧线”那么简单？

在Unity里做弓箭系统，很多人第一反应是：用LineRenderer画条弧线，再让箭沿着它飞——结果箭飞得像被磁铁吸着走，松手瞬间就卡顿，命中点永远偏移两米。我去年帮一个独立团队调弓箭逻辑，他们就是这么干的，美术说“弧线看着挺美”，程序说“贝塞尔曲线参数调好了”，但实测中玩家拉满弓射十次，七次打空，剩下三次全靠运气蹭到边缘。问题不在美术或程序，而在根本没理解抛物线弹道的本质是物理过程，不是视觉效果。

抛物线弹道的核心，是物体在重力场中仅受初速度和重力加速度影响下的自然运动轨迹。它不依赖于任何预设路径、不接受中途插值修正、不能靠“看起来像”来蒙混过关。Unity的Rigidbody2D或3D物理引擎本就内置了这套计算，但直接启用刚体模拟弓箭会带来严重副作用：碰撞检测抖动、帧率敏感、与角色动画不同步。所以真正可靠的方案，是手动复现物理公式，用Transform.position逐帧更新位置，同时完全绕过物理引擎的碰撞与力计算——这听起来反直觉，却是工业级项目（比如《Hades》《GRIS》甚至《原神》早期弓箭原型）普遍采用的折中解法。

关键词“Unity”“弓箭”“抛物线弹道”“完整代码”背后，实际藏着三层需求：第一层是数学正确性——必须严格满足 $ y = x \tan\theta - \frac{g x^2}{2 v_0^2 \cos^2\theta} $ 这个经典公式；第二层是交互实时性——玩家拉弓时，箭头预览弧线必须毫秒级响应，不能有1帧延迟；第三层是工程鲁棒性——要兼容斜坡地形、动态移动靶、多箭齐发、命中反馈等真实场景。这三者缺一不可，而市面上90%的教程只解决了第一层，剩下两层要么一笔带过，要么干脆回避。

我试过三种主流实现路径：纯物理刚体（Rigidbody.AddForce）、协程+Vector3.Lerp插值、以及本文将展开的手动物理积分。第一种在复杂碰撞场景下极易失控；第二种看似简单，但Lerp本质是线性插值，无法还原真实加速度变化，导致远距离射击时箭速忽快忽慢，玩家完全无法建立手感。只有第三种——用固定时间步长（Time.fixedDeltaTime）手动累加位移与速度——能同时保证数学精度、交互响应和扩展性。这不是炫技，而是从《Celeste》开发日志里抄来的经验：当物理精度和性能必须二选一时，宁可放弃引擎内置物理，也要守住玩家的操作反馈闭环。

2. 抛物线公式的Unity化落地：从纸面推导到代码变量映射

很多教程直接甩出一段代码，却不解释每个参数为什么是那个值。结果开发者复制粘贴后发现：箭飞得太高、太低、太快、太慢，或者拉弓越久箭反而越近……问题全出在公式与Unity坐标系、单位制、时间系统的错配。我们得把教科书里的符号，一个一个按Unity的语境重新锚定。

先看核心公式：
$$ y = x \tan\theta - \frac{g x^2}{2 v_0^2 \cos^2\theta} $$

这个公式默认以发射点为原点，x轴水平向右，y轴竖直向上，g取正值（9.8）。但Unity的World Space里，y轴确实是向上，可重力方向是-y轴，且Physics.gravity.y默认是-9.81。如果直接套用公式，g代入9.81会导致符号错误——箭会往上飞而不是下坠。所以第一步必须统一符号体系：在代码中，g取绝对值（9.81），所有重力相关计算显式添加负号。这是无数人踩坑的第一步，连Unity官方示例文档都曾在此处含糊其辞。

第二步是初速度 $v_0$ 的来源。现实中弓箭初速由弓的磅数、箭重、拉距决定，但游戏里我们不需要模拟这些物理细节。更合理的设计是：将玩家拉弓长度映射为初速度，而非角度。因为玩家操作的是“拉多长”，不是“抬多高”。我实测过20+款商业游戏，包括《The Witcher 3》的猎魔人弓箭系统，全部采用“拉距→初速”映射，角度则由瞄准方向动态计算。这样做的好处是：玩家拉满弓时箭速恒定，手感稳定；若用“拉距→角度”，同一拉距下不同瞄准高度会导致初速跳变，射击体验碎片化。

具体映射关系如下：

定义最大拉距maxDrawLength = 1.5f（单位：Unity世界单位，约1.5米）
定义最小初速minVelocity = 15f（对应轻拉）
定义最大初速maxVelocity = 45f（对应满弓）
实际初速v0 = Mathf.Lerp(minVelocity, maxVelocity, drawRatio)，其中drawRatio = currentDrawLength / maxDrawLength

提示：不要用Mathf.Pow(drawRatio, 2)或指数映射。我测试过，线性映射（Lerp）最符合玩家直觉——拉一半，速度刚好是中间值；而平方映射会让前30%拉距几乎不增加速度，后70%又暴涨，导致新手永远找不到“手感阈值”。

第三步是发射角度 $\theta$ 的获取。它不是玩家直接输入的，而是由瞄准方向向量在XZ平面（3D）或X轴（2D）上的投影夹角决定。关键陷阱在于：Unity的transform.forward是世界坐标系向量，但抛物线公式要求的是相对于发射点的局部水平面。如果角色站在斜坡上，transform.forward会包含Y分量，直接取Vector3.Angle会算错。正确做法是：先将瞄准向量投影到水平面（Y=0），再计算与X轴夹角。代码片段如下：

// 3D场景下获取水平瞄准方向 Vector3 aimDirection = transform.forward; aimDirection.y = 0f; // 投影到XZ平面 if (aimDirection.sqrMagnitude < 0.001f) aimDirection = Vector3.forward; float theta = Vector3.Angle(Vector3.forward, aimDirection); // 注意：Angle返回0~180度，需根据Z分量正负判断左右 theta *= Mathf.Sign(aimDirection.z); // 转为-180~180度 theta = Mathf.Deg2Rad * theta; // 转弧度

第四步是重力g的取值。Physics.gravity.y = -9.81，但公式中g应为正值。因此所有计算中，重力加速度项统一写作-Physics.gravity.y（即+9.81）。这个细节在调试时至关重要：当你发现箭下坠太慢，第一反应不该是调大g，而应检查是否误用了Physics.gravity.y的负值。

最后是坐标系转换。公式输出的是相对于发射点的(x,y)偏移，但Unity需要的是世界坐标。因此最终位置为：
worldPosition = launchPoint + x * horizontalDirection + y * Vector3.up
其中horizontalDirection是前述投影后的单位向量。这里绝不能用transform.right或transform.forward原始向量，必须用归一化后的水平投影向量，否则在角色旋转时箭会沿错误方向飞行。

3. 实时预览弧线：用LineRenderer绘制可交互的物理轨迹

玩家拉弓时，箭头前方必须实时显示一条平滑弧线，预示箭的落点。这不是装饰，而是核心交互反馈——没有它，玩家无法建立“拉多长→打多远”的肌肉记忆。但LineRenderer的常见用法存在三个致命缺陷：一是顶点数量固定导致远距离弧线锯齿；二是不随时间衰减导致多箭同时预览时视觉混乱；三是未考虑地形遮挡导致预览点落在山体内部。

我采用的方案是：动态生成顶点数，每帧重建整条弧线，并叠加地形射线检测。具体分四步：

3.1 动态顶点采样策略

固定采样10个点？不行。近距离（<10m）10点足够，但远距离（>50m）会出现明显折线。正确做法是：按飞行时间等分，而非按距离等分。因为抛物线在空中时间与初速、角度强相关，时间维度才是物理本质。计算总飞行时间 $t_{total} = \frac{2 v_0 \sin\theta}{g}$，然后按TimeStep = t_total / desiredPointCount切分。desiredPointCount设为30~50之间，通过Mathf.Clamp限制最小20点、最大60点，确保近处细腻、远处不卡顿。

3.2 弧线顶点物理计算

对每个时间点t，计算：

水平位移x = v0 * Mathf.Cos(theta) * t
垂直位移y = v0 * Mathf.Sin(theta) * t - 0.5f * g * t * t
世界位置pos = launchPoint + x * horizontalDir + y * Vector3.up

注意：此处g必须用Mathf.Abs(Physics.gravity.y)，且theta是弧度值。我见过太多人在这里用错角度制，导致预览弧线完全偏离实际弹道。

3.3 地形穿透过滤

预览弧线必须“看见”地形。在每个顶点位置向下发射射线，检测是否击中地面或障碍物。若击中，该顶点及后续所有顶点颜色设为红色（表示已击中），并截断绘制。关键技巧是：射线检测使用Physics.Raycast而非Physics.SphereCast，因为后者开销大且易漏检薄障碍物。射线长度设为y + 0.1f（略大于当前Y偏移），避免因浮点误差错过地面。

// 对每个预览点pos执行 RaycastHit hit; if (Physics.Raycast(pos, Vector3.down, out hit, y + 0.1f, groundLayerMask)) { previewPoints[i] = hit.point; // 截断到命中点 for (int j = i; j < previewPoints.Length; j++) previewColors[j] = Color.red; break; }

3.4 性能优化与视觉增强

LineRenderer每帧重建60个顶点看似开销大，但实测在移动端帧率无影响——因为SetPositions是Native调用，比反复Instantiate对象高效百倍。真正耗时的是射线检测。优化方案：仅对前15个顶点（约前2/3飞行时间）做射线检测，后段默认安全。视觉上，用渐变色增强深度感：起点白色（高亮），中段浅灰，终点半透明红（命中提示）。代码中通过lineRenderer.colorGradient设置，比逐点赋色更高效。

注意：LineRenderer的widthMultiplier别设太大（建议0.05~0.15）。我曾见某项目设成0.5，导致远距离弧线粗如管道，完全失去预览意义。宽度应随距离衰减：width = Mathf.Lerp(0.12f, 0.03f, distanceToCamera / 30f)。

4. 箭体飞行控制：手动积分实现零延迟、高精度运动

这才是整个系统的心脏。网上90%的“抛物线实现”用Vector3.Lerp或iTween，结果就是箭飞得像坐电梯——匀速上升、匀速下降，完全没有重力加速度的真实感。真正的抛物线运动，速度是连续变化的：上升段减速，顶点瞬时垂直速度为0，下降段加速。这只能通过手动积分（numerical integration）实现。

Unity提供两种时间基准：Update()（每帧调用，帧率波动）和FixedUpdate()（固定频率，通常50Hz）。抛物线运动必须用FixedUpdate()，否则帧率波动会导致同一拉距下箭的落点漂移——60帧时飞得远，30帧时飞得近，玩家会疯掉。但FixedUpdate()有个陷阱：它不保证与Update()同步，若在FixedUpdate()中更新位置，而Update()中读取位置做动画，会出现1帧延迟。解决方案是：在FixedUpdate()中计算下一帧位置，在Update()中用SmoothDamp做亚像素平滑。

手动积分分三步：

4.1 状态初始化

在发射瞬间，记录：

launchPosition = transform.position
launchTime = Time.time（全局时间戳，非delta）
v0 = calculatedVelocity
theta = calculatedAngleInRadians
g = Mathf.Abs(Physics.gravity.y)
isFlying = true

关键经验：不要存velocity向量！存v0和theta，每次计算都从原始参数重算。因为velocity向量在飞行中会因碰撞、外力改变，而v0和theta是发射时的确定值，永不变更。这是我重构第七版弓箭系统才悟出的——状态越少，越不易出错。

4.2 FixedUpdate中的物理积分

每帧执行：

float t = Time.time - launchTime; // 自发射起经过的时间 float x = v0 * Mathf.Cos(theta) * t; float y = v0 * Mathf.Sin(theta) * t - 0.5f * g * t * t; // 水平方向向量（已投影到XZ平面） Vector3 horizontalDir = aimDirectionNormalized; horizontalDir.y = 0f; horizontalDir.Normalize(); Vector3 targetPos = launchPosition + x * horizontalDir + y * Vector3.up; // 应用位置（不直接赋值，为平滑留余地） nextPosition = targetPos;

注意：t必须用Time.time - launchTime，而非累加Time.fixedDeltaTime。因为Time.fixedDeltaTime可能因设备性能波动（如iOS后台降频），而Time.time是单调递增的全局时钟，精度达毫秒级。

4.3 Update中的亚像素平滑

在Update()中：

if (isFlying) { // SmoothDamp避免瞬移，但目标是nextPosition，不是targetPos transform.position = Vector3.SmoothDamp( transform.position, nextPosition, ref velocity, 0.05f // 平滑时间，0.05秒≈3帧，人眼无感 ); }

velocity是Vector3类型缓存变量，用于SmoothDamp内部计算。这个设计让箭的运动既保持物理精确性（nextPosition严格按公式），又消除帧间跳跃（SmoothDamp补足亚像素位移）。

4.4 碰撞与命中判定

绝不依赖OnCollisionEnter！因为手动更新transform.position会绕过物理引擎的碰撞检测。正确方案是：每帧在nextPosition处执行球形射线检测。用Physics.SphereCast从上一帧位置向nextPosition发射，半径设为箭模型包围盒的0.3倍。若击中，则：

立即停止飞行（isFlying = false）
播放命中音效与粒子
根据击中物材质设置不同反馈（木头溅木屑、金属火花、肉体血迹）
计算伤害（需传入hit.normal计算入射角）

踩坑实录：曾有项目用Physics.Raycast替代SphereCast，结果箭穿过栅栏缝隙——因为射线是无限细的线，而箭有体积。SphereCast模拟真实箭体，是唯一可靠方案。

5. 复杂场景适配：斜坡、移动靶、多箭齐发的实战解法

抛物线系统上线后，美术提了个需求：“让弓箭能射上山坡，现在箭全打在山脚”。策划说：“敌人会边跑边跳，箭得能预判”。QA报告：“三连射时第二支箭轨迹错乱”。这些问题暴露了基础抛物线模型的局限性。解决它们不靠改公式，而靠在物理层之上叠加一层‘场景适配逻辑’。

5.1 斜坡地形的发射点校准

当角色站在斜坡上，transform.position是角色脚部中心点，但弓的发射点应在角色肩部前方。若直接以此为原点，箭会从脚底射出，穿地而过。正确做法是：用射线检测获取实际地面高度，动态调整发射点Y坐标。在发射前执行：

Ray ray = new Ray(transform.position + Vector3.up * 1.5f, Vector3.down); if (Physics.Raycast(ray, out RaycastHit hit, 2f, terrainLayer)) { // 发射点Y = 地面Y + 角色身高 * 0.7（肩部高度比例） launchPosition.y = hit.point.y + characterHeight * 0.7f; } else { launchPosition.y = transform.position.y + 1.2f; // 默认肩高 }

这个1.5f的射线起点高度和0.7f的比例，是我实测20+个角色模型后确定的黄金值——太低会穿地，太高会悬空。

5.2 移动靶的提前量计算

静态靶用基础公式即可，但对匀速移动的靶，必须计算提前量（lead calculation）。这不是简单加个偏移，而是解一个方程：箭飞行时间t内，靶移动距离 =targetVelocity * t，而箭的水平位移 =v0 * cosθ * t。二者在水平面上的矢量差，就是瞄准点偏移。公式为：

$$ \vec{d}{lead} = \vec{v}{target} \cdot t $$
其中t是解方程 $|\vec{p}{target} + \vec{v}{target} \cdot t - \vec{p}_{launch}| = v_0 \cdot t$ 得到的正实根。

实践中，用迭代法求解比解析解更稳：假设t=1s，计算靶位置，再算箭到该点所需时间t'，用t'更新，3次迭代收敛。代码中封装为CalculateLeadTime(targetPos, targetVel, v0)，返回精确t值，再代入基础抛物线公式即可。

5.3 多箭齐发的资源隔离

三连射时，若所有箭共享同一launchTime，它们会完全重叠。必须为每支箭分配独立计时器。但创建3个MonoBehaviour实例开销大。我的方案是：用对象池管理箭体，每个箭体持有一个ArrowState结构体，内含所有私有状态（launchTime,v0,theta,launchPosition）。结构体比类更省内存，且GC压力为零。对象池预加载20个箭体，GetArrow()时重置ArrowState，ReturnArrow()时清空状态。

5.4 风力与空气阻力的轻量扩展

商业项目常需风力效果。全真模拟流体力学不现实，但可加一层线性风偏移：每帧在水平面添加windForce * Time.fixedDeltaTime的位移。关键是风向量必须是世界坐标，且只影响水平位移x，不影响垂直位移y（重力主导）。阻力则简化为速度衰减：v0 *= Mathf.Pow(dragFactor, t)，其中dragFactor=0.999f。这两者叠加后，箭的落点会自然偏移，无需重写核心公式。