1. 核心能力速览看到“跳跳男车祸超级跳跳男”这个标题先别急着笑。剥掉梗的外壳它其实精准命中了游戏开发里两个最难调、最容易翻车的模块角色跳跃手感和碰撞响应。一个篮球小游戏里玩家按一下空格角色起跳高度不对、起跳后飘在半空、落地像踩在棉花上手感立刻崩而一次“车祸”式的剧烈碰撞如果没有正确的冲量计算和状态切换角色就会穿墙、卡进地板、或者被弹到地图外。这篇文章不讲某个具体开源项目而是把这两个技术点拆开从参数设计、代码实现、批量验证到排错清单完整走一遍。先说结论式的核心特点方便你判断要不要往下读跳跃不是一条重力曲线。可用手感至少需要起跳冲量、上升重力缩放、顶点悬停、下落加重四段分离控制单靠Rigidbody.AddForce一个数值是调不出来的。二段跳不是把跳跃调用两次。空中跳跃要处理冲量衰减、次数限制、落地重置、动画打断否则会出现无限跳、跳跃穿模、落地翻滚卡死。“车祸”是碰撞响应的通俗说法。真正要算的是相对速度、接触法线、质量比和判定阈值而不是简单写一个OnCollisionEnter就完事。手感三件套缺一不可输入缓冲jump buffer、土狼时间coyote time、落地锁定landing lock。少任何一个玩家都会觉得“我明明按了”。参数必须能批量扫描。靠手动拖 Inspector 调手感一天调不出三组有效数据用脚本跑参数网格半小时能出一张对比表。本文演示的实操内容覆盖环境准备与物理步长设置、跳跃控制器完整代码、二段跳实现、碰撞冲量计算与伤害判定、动画状态机参数联动、基于配置文件的参数批量验证脚本、性能观察方法、以及一份常见问题排查表。适合正在做平台跳跃、篮球、跑酷类原型开发的 Unity 使用者也适合想理解“手感到底由什么构成”的独立开发者。全文代码基于 Unity C#物理公式和参数思路可以平移到 Godot、Unreal 或者自己写的 2D 引擎里。2. 适用场景与使用边界这个主题的适用范围比想象中宽。任何需要“角色在地面上反复起跳、落地、被撞击”的玩法都绕不开这套东西平台跳跃、跑酷、篮球对抗、格斗游戏的击飞、甚至开放世界里的攀爬落地。核心逻辑是通用的区别只在于参数偏好——卡通风格要夸张的滞空和弹性拟真体育游戏要更短的滞空和更硬的落地反馈。但有几条边界必须提前说清楚否则容易走弯路。第一卡通手感和拟真物理是两条路。如果你追求“超级跳跳男”那种夸张的二段跳、空中变向、踩人弹起就不要指望 PhysX 的默认重力给你答案。你需要主动改写重力曲线、关闭部分物理惯性、甚至在顶点做短暂的速度钳制。反过来如果你要做拟真篮球就不要给角色加空中二段跳那会直接破坏物理可信度。这两套参数不通用不要混着调。第二不要用真实球员、真实球队标识、真实转播画面做素材。这是最容易被忽略的合规问题。角色外观、队服配色、队徽、球场贴图全部建议自创或使用明确可商用的资源。名字也不要直接使用真实运动员姓名。技术验证阶段用胶囊体加色块就够了等手感定下来再换皮。第三碰撞响应的“伤害”逻辑要和物理分离。物理只负责让两个物体不重叠、给出正确的接触点和法线伤害、眩晕、倒地、扣血这些属于游戏逻辑层应该由物理事件触发、由状态机处理。把伤害计算写进OnCollisionEnter里是新手最常见的架构错误后期加护盾、加无敌帧、加受击硬直时会改到崩溃。第四联机和回放场景要慎用物理驱动的位置。如果你的游戏需要帧同步或者录像回放角色位置最好由确定性运动学计算物理只做检测不做驱动。PhysX 在不同平台、不同 CPU 上不保证完全一致的浮点结果这一点在做多人对战时要提前决策。第五调试工具要一开始就建。跳跃手感是“看不见的曲线”没有可视化调试你只能靠反复试玩猜参数。后面章节会给出一套最小调试方案包括轨迹绘制和关键帧打点投入产出比极高。3. 环境准备与前置条件整体硬件门槛很低这类项目不吃显卡普通开发机完全够用。真正影响结果的不是 GPU而是物理步长和渲染帧率的解耦设置。推荐环境如下项目建议配置说明引擎Unity 2021 LTS 及以上2022/6000 也可物理 API 基本一致脚本运行时.NET Standard 2.1默认即可渲染管线Built-in 或 URP 均可本项目不依赖高级渲染特性物理引擎PhysX默认2D 场景可换 Physics2D输入系统旧 Input Manager 或新 Input System新输入系统更适合做输入缓冲调试工具Unity Profiler Physics DebuggerPhysics Debugger 必开硬件任意近五年内的 CPU 集显无独显要求磁盘2GB 以上主要是引擎缓存关键的工程设置有三处务必先改否则后面所有参数都白调。第一处是固定时间步长。默认Fixed Timestep是 0.0250Hz对跳跃手感来说太粗糙角色在空中会出现明显的“台阶感”。建议改成 0.016666760Hz或者直接 0.01100Hz代价是物理计算量上升但对这种小场景完全无压力。Edit - Project Settings - Time Fixed Timestep: 0.0166667 Maximum Allowed Timestep: 0.1第二处是刚体插值。角色刚体必须开启Interpolate否则物理更新频率和渲染频率不一致时角色会抖动。同时建议把Collision Detection设为Continuous防止高速下落时穿过地面。第三处是自动同步变换。Physics.autoSyncTransforms默认关闭是正确的不要为了图省事打开它会在每次读取 Transform 时强制同步物理状态性能开销明显而且会掩盖你代码里更新顺序的错误。// 初始化阶段的全局设置放在启动脚本里 using UnityEngine; public class PhysicsBootstrap : MonoBehaviour { void Awake() { // 物理以 100Hz 推进渲染仍按显示器刷新率 Time.fixedDeltaTime 0.01f; // 保持默认关闭避免隐式同步带来的性能损耗 Physics.autoSyncTransforms false; } }前置检查清单建议逐条确认物理层碰撞矩阵是否配置角色层和地面层要能碰、和触发区要分开、角色碰撞体是否是胶囊体而不是盒子胶囊体在斜面和小台阶上的表现远好于 BoxCollider、Rigidbody的Freeze Rotation是否勾选角色不该被物理转飞、地面碰撞体是否用了 MeshCollider能换 BoxCollider 就换性能和稳定性都更好。这四项没做好后面调参就是在一个错误的基线上做无用功。4. 跳跃物理核心实现与二段跳跳跃手感的本质是速度曲线的分段设计。如果只用一次冲量加恒定重力得到的是一个完美抛物线物理正确但手感极差因为真实的人类运动不是抛物线起跳瞬间爆发力强接近顶点时减速明显下落阶段受重力加速更快。工程上通常把它拆成四段来控制起跳段给一个向上的初速度同时立刻把水平速度调整为玩家输入方向保证“跳出去”的方向感。上升段重力乘以一个小于 1 的系数比如 0.8让角色上升更“轻”滞空时间变长。顶点段当竖直速度的绝对值小于某个阈值时短暂把重力进一步压低制造一个“悬停感”。这个悬停是卡通手感的核心。下落段重力乘以一个大于 1 的系数比如 1.8 到 2.5让落地干脆利落不拖泥带水。配合这套曲线还需要三个“容错”机制。土狼时间指角色离开平台边缘后的短时间内一般 0.1 到 0.15 秒仍然允许起跳解决“我明明还在平台上”的心理落差。输入缓冲指玩家在落地前按下跳跃键系统记录下来落地瞬间自动执行解决“我明明按了却没跳”的挫败感。可变跳跃高度指玩家松开跳跃键时如果角色仍在上升就把竖直速度按比例削减实现“短按小跳、长按大跳”。下面是完整的跳跃控制器实现包含了上述全部机制。using UnityEngine; [RequireComponent(typeof(Rigidbody))] [RequireComponent(typeof(CapsuleCollider))] public class JumpController : MonoBehaviour { [Header(跳跃基础参数)] public float jumpVelocity 8f; // 起跳初速度 public float maxJumpCount 2; // 最大跳跃次数2 表示二段跳 public float airJumpScale 0.85f; // 空中跳跃冲量衰减 [Header(重力曲线)] public float riseGravityScale 0.8f; // 上升段重力倍率 public float fallGravityScale 2.2f; // 下落段重力倍率 public float apexThreshold 1.5f; // 顶点判定速度阈值 public float apexGravityScale 0.5f; // 顶点重力倍率 [Header(容错窗口)] public float coyoteTime 0.12f; // 土狼时间 public float jumpBufferTime 0.12f; // 输入缓冲 public float jumpCutFactor 0.5f; // 松键削减系数 private Rigidbody rb; private CapsuleCollider capsule; private int jumpUsed; private float coyoteCounter; private float bufferCounter; private bool isGrounded; private bool jumpReleased true; void Awake() { rb GetComponentRigidbody(); capsule GetComponentCapsuleCollider(); rb.freezeRotation true; rb.interpolation RigidbodyInterpolation.Interpolate; rb.collisionDetectionMode CollisionDetectionMode.Continuous; } void Update() { // 输入采集放在 Update物理执行放在 FixedUpdate if (Input.GetButtonDown(Jump)) { bufferCounter jumpBufferTime; jumpReleased false; } if (Input.GetButtonUp(Jump)) { jumpReleased true; } if (bufferCounter 0f) bufferCounter - Time.deltaTime; if (coyoteCounter 0f) coyoteCounter - Time.deltaTime; } void FixedUpdate() { CheckGrounded(); ApplyGravityCurve(); TryJump(); ApplyJumpCut(); } void CheckGrounded() { // 用射线而不是仅靠碰撞事件避免斜坡和台阶误判 float radius capsule.radius * 0.95f; Vector3 origin transform.position capsule.center Vector3.down * (capsule.height * 0.5f - radius); bool ground Physics.SphereCast(origin, radius, Vector3.down, out _, 0.08f, LayerMask.GetMask(Ground), QueryTriggerInteraction.Ignore); if (ground !isGrounded) { jumpUsed 0; coyoteCounter coyoteTime; } if (!ground isGrounded) { coyoteCounter coyoteTime; } isGrounded ground; } void ApplyGravityCurve() { float vy rb.velocity.y; float scale vy 0f ? fallGravityScale : riseGravityScale; if (Mathf.Abs(vy) apexThreshold !isGrounded) { scale apexGravityScale; } // 用额外加速度实现曲线基础重力由 Physics.gravity 提供 Vector3 extra Vector3.down * (Physics.gravity.magnitude * (scale - 1f)); rb.AddForce(extra, ForceMode.Acceleration); } void TryJump() { if (bufferCounter 0f) return; bool canGroundJump isGrounded || coyoteCounter 0f; bool canAirJump !canGroundJump jumpUsed maxJumpCount; if (!canGroundJump !canAirJump) return; float v canGroundJump ? jumpVelocity : jumpVelocity * airJumpScale; Vector3 vel rb.velocity; vel.y v; rb.velocity vel; jumpUsed canGroundJump ? 1 : jumpUsed 1; bufferCounter 0f; coyoteCounter 0f; } void ApplyJumpCut() { if (!jumpReleased || isGrounded) return; if (rb.velocity.y 0f) { Vector3 vel rb.velocity; vel.y * jumpCutFactor; rb.velocity vel; } } }这段代码里有几个细节值得单独说。CheckGrounded用SphereCast而不是OnCollisionStay原因是碰撞事件在角色贴墙、站在斜坡边缘、或者被其他刚体挤压时会误报导致角色在墙边可以无限跳。用向下球体检测配合一个独立的Ground层判断稳定得多。jumpUsed的计数逻辑要区分地面跳和空中跳地面跳记为 1空中跳在此基础上累加而不是每次跳跃都从 0 开始否则二段跳会变成三段跳。ApplyGravityCurve用的是增量叠加而不是直接改rb.velocity.y。这一点很重要如果直接乘算速度会和物理引擎自身的重力积分冲突导致不同帧率下手感不一致。用ForceMode.Acceleration叠加额外加速度物理引擎负责积分结果更稳定。参数表参考卡通风格可以按项目调整参数卡通手感拟真体育影响jumpVelocity8 - 125 - 7起跳高度riseGravityScale0.7 - 0.91.0滞空时间fallGravityScale2.0 - 3.01.3 - 1.6落地干脆度apexGravityScale0.4 - 0.61.0顶点悬停感coyoteTime0.1 - 0.150.05边缘容错jumpBufferTime0.1 - 0.150.08连跳顺畅度airJumpScale0.8 - 0.9不适用二段跳力度衰减5. 碰撞响应与撞击判定“车祸”这个词用得很准因为高强度碰撞最难处理的不是“碰上了”而是“碰上之后怎么反应”。一个 20 米每秒的自由落体撞上地面和一个缓慢走上斜坡在物理引擎眼里都是接触事件但游戏逻辑上完全是两回事。所以碰撞系统的设计原则是物理层只负责不穿模逻辑层负责分级响应。分级依据是相对速度、接触法线方向和物体质量。先看相对速度怎么算。碰撞瞬间用当前速度减去上一个物理帧记录的速度得到加速度近似值再乘以质量得到冲量。这个值比单纯看速度更准确因为它反映了“突然停止”的程度。using UnityEngine; public class ImpactHandler : MonoBehaviour { [Header(判定阈值)] public float lightImpactSpeed 4f; // 轻撞 public float heavyImpactSpeed 9f; // 重撞 public float lethalImpactSpeed 15f; // 致命撞击 [Header(受击表现)] public float stunDurationLight 0.2f; public float stunDurationHeavy 0.8f; private Rigidbody rb; private Vector3 lastVelocity; private float lastImpactTime; void Awake() { rb GetComponentRigidbody(); } void FixedUpdate() { lastVelocity rb.velocity; } void OnCollisionEnter(Collision collision) { // 防止同一次接触重复触发 if (Time.time - lastImpactTime 0.1f) return; lastImpactTime Time.time; Vector3 relVel lastVelocity - collision.relativeVelocity; float impactSpeed relVel.magnitude; // 只有法线方向接近竖直向上的撞击才判定为落地 Vector3 normal collision.GetContact(0).normal; if (impactSpeed lethalImpactSpeed) { OnLethalImpact(impactSpeed, normal); } else if (impactSpeed heavyImpactSpeed) { OnHeavyImpact(impactSpeed, normal); } else if (impactSpeed lightImpactSpeed) { OnLightImpact(impactSpeed, normal); } } void OnLightImpact(float speed, Vector3 normal) { // 轻微震动不打断操作 Debug.Log($[Impact] light {speed:F1}, normal {normal}); } void OnHeavyImpact(float speed, Vector3 normal) { // 进入硬直状态动画播放受击 GetComponentPlayerStateMachine()?.EnterStun(stunDurationHeavy); } void OnLethalImpact(float speed, Vector3 normal) { // 触发倒地或出界流程 GetComponentPlayerStateMachine()?.EnterDown(); } }这段代码的核心在collision.relativeVelocity。它返回的是两个刚体碰撞瞬间的相对速度比用lastVelocity简单相减更准因为后者在高速运动下误差明显。实际项目里可以把两种方式都算一遍做双保险取较大值作为最终冲量。另外要注意collision.GetContact(0)在多接触点情况下只取第一个如果角色是多点着地更严的做法是遍历所有接触点、取法线 y 分量最大的那个。碰撞穿模是另一个高频问题尤其在“超级跳跳男”这种高速下落的场景。防护手段有三层第一把角色的Collision Detection设为Continuous地面设为Continuous Speculative。前者对所有动态刚体做连续检测后者对静态碰撞体做推测性检测组合起来能挡住绝大多数穿透。第二避免角色自己碰撞自己。角色内部的骨骼、武器挂点如果挂了碰撞体容易互相挤压产生诡异位移统一放到一个不参与角色间碰撞的层里。第三给地面加一层薄的“兜底平面”。即使主碰撞体失效角色也会被兜底平面接住不至于掉出地图。这一层可以做得比主地面低 0.5 米玩家看不见。碰撞场景判定依据推荐处理正常落地法线 y 0.7速度 4播放落地缓冲动画高处落地法线 y 0.7速度 4 - 9落地硬直 相机震动高速坠落法线 y 0.7速度 15倒地状态 输入屏蔽侧面撞墙法线 y 0.3速度衰减不判定伤害被其他角色撞飞相对速度 8对方质量更大击飞状态 失控时间贴墙滑动持续接触速度低允许沿墙滑落禁止墙面跳6. 动画状态机与手感联动物理参数调好了如果动画跟不上手感依然是碎的。最典型的问题是“角色已经落地了动画还在空中姿态”或者“二段跳触发了但动画没播”。解决办法是把状态机作为唯一的真相来源物理只负责计算状态机负责决定播什么、能不能操作。状态机的关键参数不宜过多四个足够Grounded是否在地面、VerticalSpeed竖直速度用于混合上升下降动画、JumpCount当前跳跃次数、IsStunned是否受击硬直。转移规则写死在代码里不要依赖 Animator 的 Transition 条件互相触发容易产生竞态。using UnityEngine; public class PlayerStateMachine : MonoBehaviour { private Animator anim; private Rigidbody rb; private float stunTimer; public bool CanControl { get; private set; } true; void Awake() { anim GetComponentAnimator(); rb GetComponentRigidbody(); } void Update() { if (stunTimer 0f) { stunTimer - Time.deltaTime; if (stunTimer 0f) ExitStun(); } anim.SetFloat(VerticalSpeed, rb.velocity.y); anim.SetBool(IsStunned, stunTimer 0f); } public void EnterStun(float duration) { stunTimer duration; CanControl false; anim.SetTrigger(Hit); } void ExitStun() { CanControl true; } public void EnterDown() { stunTimer 999f; CanControl false; anim.SetTrigger(Down); } }落地动画的关键是过渡时间。从空中状态切到落地状态混合时间设为 0.05 到 0.08 秒太短会有硬切感太长会显得拖沓。同时落地动画的前几帧可以带一个位移下沉让角色的视觉重心短暂降低这个细节对手感提升非常明显成本却几乎为零。另外强烈建议加一套动画事件打点。在起跳帧、最高点帧、落地帧分别挂一个事件把时间戳打印出来和物理状态日志对比。如果发现动画总是比物理慢 2 到 3 帧那就是混合时间或者 Animator 更新顺序的问题。把 Animator 的Update Mode从Normal改成Animate Physics可以让动画和物理帧对齐代价是响应略慢一帧需要权衡。6.1 输入与操作的耦合还有一点常被忽略受击硬直期间必须屏蔽跳跃输入但不能屏蔽输入缓冲。也就是说玩家在硬直中按了跳跃这个输入要记录下来硬直结束的瞬间如果还在地面就立刻执行。否则玩家会觉得“我一落地就被打起来想跑跑不掉”。缓冲时间可以设得短一点0.08 秒左右既能接住操作又不会让玩家蒙混过关。7. 参数配置与批量验证手感调参最忌讳的就是“改一个数字运行一次感觉一下”。这套流程一天调不了几组参数而且凭主观感受很难判断哪一组更好。更工程化的做法是把参数外置成配置用脚本批量跑输出可对比的数据表。第一步把参数抽到一个 JSON 文件里方便脚本批量替换。{ presets: [ { name: cartoon_high, jumpVelocity: 11.0, riseGravityScale: 0.75, fallGravityScale: 2.6, apexGravityScale: 0.45, coyoteTime: 0.14, maxJumpCount: 2, airJumpScale: 0.85 }, { name: realistic_mid, jumpVelocity: 6.2, riseGravityScale: 1.0, fallGravityScale: 1.5, apexGravityScale: 1.0, coyoteTime: 0.06, maxJumpCount: 1, airJumpScale: 1.0 } ] }第二步用 Python 复现同一套物理积分公式在本地跑参数网格。因为跳跃本质上是几百毫秒的运动完全可以在 CPU 上瞬间模拟上万次得到起跳高度、滞空时间、落地速度这些硬指标先用数值筛掉明显不合理的组合再去引擎里做主观确认。import json import itertools import csv G 9.81 DT 0.01 MAX_T 3.0 def simulate(v0, rise_scale, fall_scale, apex_scale, apex_thr1.5, air_jumpNone, air_scale0.85): y, v 0.0, v0 t 0.0 max_h 0.0 used_air False land_t None while t MAX_T: if v 0: scale fall_scale elif abs(v) apex_thr: scale apex_scale else: scale rise_scale v - G * scale * DT y v * DT t DT max_h max(max_h, y) # 空中跳跃在接近顶点时触发 if air_jump and not used_air and v 0.5: v air_jump * air_scale used_air True if y 0 and t 0.05: land_t t break return max_h, land_t, abs(v) rows [] grid itertools.product( [8.0, 9.0, 10.0, 11.0, 12.0], [0.7, 0.8, 0.9, 1.0], [1.5, 2.0, 2.5, 3.0], [0.4, 0.5, 0.6, 1.0], ) for v0, rise, fall, apex in grid: h, t_land, v_land simulate(v0, rise, fall, apex) rows.append({ jump_velocity: v0, rise_scale: rise, fall_scale: fall, apex_scale: apex, max_height: round(h, 3), air_time: round(t_land or 0, 3), land_speed: round(v_land, 3), }) with open(jump_grid.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows) print(f共生成 {len(rows)} 组参数组合)跑完之后你会得到几百组数据按air_time和land_speed两个维度筛滞空时间在 0.6 到 0.9 秒之间、落地速度在 8 到 12 之间的组合是卡通手感比较舒服的区间。先用数值筛到 20 组再进引擎里逐个试效率比盲调高十倍以上。第三步如果要做自动化回归可以用 Unity 的批处理模式跑固定输入序列的测试场景输出轨迹日志。# 需要按实际项目路径和测试脚本名调整 Unity \ -batchmode \ -nographics \ -projectPath /path/to/your_project \ -executeMethod TestRunner.RunJumpRegression \ -logFile - \ -quit本主题不涉及网络接口 API如果你的项目需要把参数下发给服务端做远程配置可以在这个 JSON 结构上直接扩展一个GET /api/presets的读取逻辑但手感和服务端无关不建议把手感参数做成动态下发会导致不同客户端表现不一致破坏公平性。8. 资源占用与性能观察这类项目的性能瓶颈几乎从不在 GPU而在物理计算和 GC 分配。观察方法很直接打开 Unity Profiler看Physics.Processing、Physics.LateUpdate和GC.Alloc三条曲线。Fixed Timestep从 0.02 降到 0.01物理计算量大约翻倍。在一个只有几十个刚体的小场景里这个开销通常在 0.5 毫秒以内完全可接受。但如果场景里有几百个道具、球、可破坏物就要做取舍角色用 0.01道具用插值补偿不要全场景统一提高频率。GC.Alloc是另一个隐藏杀手。上面代码里Physics.SphereCast如果没有加out参数会返回一个新数组每次调用都产生垃圾。同理GetContact(0)在某些情况下会分配内存。做法是在Awake里预分配一个RaycastHit[]缓冲用Physics.SphereCastNonAlloc替代SphereCast把每帧分配压到 0。降低碰撞检测开销还有几个常规手段把静态地面合并成少量大碰撞体而不是几百个小瓦片给远处不参与玩法的物体关掉物理用层碰撞矩阵把不相关的组合直接屏蔽这比在代码里判断if (other.tag ...)高效得多。需要重点关注的指标是帧率稳定性而不是峰值帧率。跳跃手感对卡顿极其敏感一次 30 毫秒的卡顿会让玩家在起跳瞬间感到明显延迟。建议在开发阶段把Application.targetFrameRate固定下来关掉垂直同步做测试确认在最差的场景下物理帧也能稳定推进。9. 常见问题与排查方法问题现象可能原因排查方式解决方案角色在墙边能无限跳着地检测用了碰撞事件贴墙误判打印isGrounded站在墙边观察改用向下 SphereCast 独立 Ground 层二段跳变成三段跳jumpUsed每次跳跃重置打印跳跃次数日志地面跳记 1空中跳累加落地归零落地瞬间穿插进地面Collision Detection 为 DiscretePhysics Debugger 看接触点改 Continuous地面加兜底平面高空下落穿过地板速度过快单帧位移大于碰撞体厚度记录每帧位移量提高物理频率或加厚地面碰撞体松键后角色还在上升很久未实现跳跃削减观察松键后速度变化加jumpCutFactor上升段按比例削减空中可以随意变向水平速度在空中被完全覆盖打印水平速度空中输入乘以 0.3 - 0.6 的系数动画比物理慢半拍Animator 更新模式不匹配对比打点时间戳改用 Animate Physics 或缩短混合时间受击后无法立即起跳硬直期间丢弃了输入加输入日志硬直中记录缓冲结束后立即执行相机抖动严重相机跟随放在 Update 且无平滑观察抖动频率相机跟随放 LateUpdate加阻尼参数改了没效果脚本参数被预制体覆盖检查 Inspector 实际值统一参数来源避免多份配置排错的核心思路是先定位层再定位参数。手感问题通常分三层输入层按键有没有被识别、物理层速度曲线对不对、表现层动画和相机跟不跟得上。加日志的时候按这三层分别打点打印Time.time、按键状态、速度、位置、动画状态一比就能看出问题出在哪一层。最怕的是不分层看到“跳不起来”就去改重力参数结果真正的原因是输入被 UI 拦截了。10. 最佳实践与使用建议第一先做最小可玩原型再谈美术。胶囊体加一个方块地面把跳跃、二段跳、落地、撞击四条链路跑通全程不超过两百行代码。这一步没走通就去做角色模型和动画纯属浪费时间因为手感一旦大改动画全都要重做。第二把参数集中到一个 ScriptableObject 或 JSON 里不要散落在各个预制体上。手感参数是项目级的核心资产散落之后会出现“这个场景的角色跳得比那个场景高”的诡异问题而且没法做版本对比。第三建立一套固定的测试用例。比如原地起跳高度是否一致、连续两次跳跃的间隔是否稳定、从两米高台落下是否触发硬直、贴着墙跳是否能上去、快速连按五次跳跃键是否出现异常。这五个用例每次改动物理参数都跑一遍能挡住八成回归问题。第四输入的采集和执行必须分帧。输入在Update里记录物理在FixedUpdate里执行中间的缓冲窗口用计数器维护。混在一起写在Update里直接改速度会出现帧率越高跳得越高的问题这类 bug 极难排查。第五所有涉及角色形象、队服、球场、音效的素材确认授权再用。技术验证阶段就用纯色几何体等玩法确定、需要对外展示时再统一替换成自研或明确可商用的资源。涉及真人肖像、真实赛事画面的内容即使只是内部测试也建议提前明确使用边界。第六上线前做一次低帧率压力测试。把帧率人为压到 30 帧重新走一遍所有跳跃场景。很多手感问题在 60 帧下完全看不出来一到低端机就暴露尤其是输入缓冲和土狼时间的计时如果用Time.deltaTime累加低帧率下窗口会明显变短。如果需要继续往下扩展优先级建议是先加斜坡与台阶的着地适配SphereCast 的半径和偏移要跟着胶囊体参数走再加击飞与受击方向把碰撞法线和相对速度组合成击飞向量最后才考虑网络同步。前两步做完一个手感扎实的篮球跳跃原型就成立了剩下的都是内容填充。参数表建议留在仓库里当作文档下次开新项目直接复用能省掉至少两天的重复调参。