Unity倾斜场景DEMO搭建：斜面角色控制与相机跟随实战

看到“【灰烬溪】DEMO试玩P1 - 比萨斜楼”这个标题，多数人第一反应是点进去看乐子：一个刚放出来的游戏 DEMO，一段试玩录像，副标题还带个谐音梗。但如果你是从开发视角点进去的，注意力应该落在另一个地方——这个 DEMO 是怎么被搭出来的，它在工程上做了哪些取舍，哪些地方明显是“先跑通再说”，哪些地方又留了扩展的口子。

标题里的“比萨斜楼”是个很典型的信号。倾斜的建筑、歪掉的楼面、玩家在上面走，这件事在玩家眼里只是画面，在开发者眼里却是物理碰撞、角色控制器、重力对齐、相机跟随四件事叠在一起的高风险区域。斜面上角色会滑、会卡、会在边界抖动，相机在倾斜空间里会穿墙、会晕，碰撞体稍微做薄一点角色就会掉下去。这些坑不是玄学，是有明确解决办法的工程问题。

所以这篇文章不打算复述试玩内容，也不做游戏评测。我要做的是把它当成一个引子，把“一个可玩的 DEMO 到底要搭哪些东西、倾斜场景为什么容易翻车、怎么用最小代价把它跑通”讲清楚。读完你至少能拿到三样东西：一套可以照着做的 DEMO 搭建流程、一份斜面上角色控制的可用代码、一张遇到问题能对上的排查表。

1. DEMO 试玩内容背后，开发者应该关注什么

玩家看 DEMO 试玩，看的是玩法有没有意思、美术风格对不对味、值不值得加愿望单。开发者看同一段内容，关注点应该完全不同：它的垂直切片切在哪一刀，交互是脚本硬编的还是数据驱动的，场景是灰盒还是已经过了美术流程，帧率在复杂场景下有没有掉。

这个视角切换很重要。因为 DEMO 阶段最常见的失败不是“做得不好看”，而是“做了一堆没法改的东西”。比如把交互逻辑写死在场景里，结果策划想调一个开关位置就要程序重开工程；比如所有参数直接填在组件面板上，换一台机器就得重配一遍；比如物理参数凭手感乱调，等到正式关卡发现整套手感全都得推翻重来。

更实际的判断是：DEMO 的价值不在于它有多完整，而在于它能不能低成本地被修改和扩展。一个只能演示三分钟、但每个数值都外置、每段逻辑都能替换的 DEMO，比一个看着华丽但改一行要动全身的 DEMO 有用得多。这也是为什么很多团队在做垂直切片时，会把大量时间花在工具和数据结构上，而不是内容量上。

这篇文章面向的读者很明确：正在做或者准备做独立游戏 DEMO 的开发者，尤其是用 Unity 或 Godot 这类引擎、需要快速验证玩法的个人开发者和小团队。如果你只是想了解这款游戏本身，那这篇可能不对路；如果你想搞清楚“我手上这个 DEMO 为什么在斜面上走起来像滑冰”，往下看。

2. DEMO、垂直切片与原型：三个容易混淆的概念

很多讨论把 DEMO、原型、垂直切片混着说，但在工程上它们是三件不同的事，投入结构也完全不同。分不清这三个词，最容易出现的结果是：用原型的标准做垂直切片，做出来发现没法扩展；或者用垂直切片的标准做原型，花了两周做出来的东西连验证目的都达不到。

原型阶段允许“脏”。代码写在一个文件里、参数硬编、美术用方块，这些都不是问题，因为原型的目的就是尽快拿到“这个玩法好不好玩”的答案，答案拿到手，代码就可以扔。真正的问题出现在原型被当成正式代码继续往下写的时候——这时候你会发现，原本三天写完的逻辑，改起来要三天。

垂直切片的核心是“一小段走完全流程”。它不追求内容量，但要求这一小段从加载、交互、存档、退出都是通的，品质要达到最终目标。这就是它比原型贵得多的原因：内容可以少，管线必须全。

DEMO 则介于两者之间，但更偏工程稳定性。因为 DEMO 要发出去给别人玩，别人的机器配置、分辨率、输入设备都不一样，任何在开发机上“没复现”的问题都会在 Demo 发布后集中爆发。所以 DEMO 阶段最该做的事不是加内容，而是把边界情况堵住：窗口失焦怎么办、手柄拔掉怎么办、帧率掉到 30 怎么办。

回到“比萨斜楼”这类场景。倾斜建筑在 DEMO 里出现的概率很高，因为它视觉上足够有辨识度，实现上又不需要复杂的关卡设计。但它正好踩在物理和角色控制这两个最容易出问题的模块交界处。一个在水平地面上跑得好好的角色控制器，放到 15 度的斜面上就可能开始抖动，放到 30 度上就可能原地打滑。

3. 技术选型与环境准备

先解决选型问题。做 DEMO 用什么引擎，没有标准答案，但有三条判断线：你的玩法对物理精度的要求、团队对语言的熟悉程度、以及发布平台的限制。下面这张表是基于常见情况整理的，不代表绝对结论。

如果是第一次做 3D DEMO，我倾向于推荐 Unity，理由不是它最好，而是遇到问题时能搜到的答案最多。物理参数调不顺手、角色在斜面上抖动、打包后光照全黑，这些问题在社区里都有现成结论，能省下大量试错时间。

环境准备清单如下，具体版本请以你实际安装的为准，本文的示例不绑定具体小版本号：

• 引擎：Unity LTS 版本（长期支持版），避免用最新的预览版本做 DEMO。
• 脚本运行时：项目创建时选择与团队习惯一致的 .NET 版本，中途不要改。
• 编辑器：VS Code 或 Rider 均可，关键是配好 C# 的智能提示与调试附加。
• 版本管理：Git + Git LFS。模型、贴图、音频一律走 LFS，否则仓库很快就会膨胀到没法克隆。
• 输入系统：新项目建议直接用新版 Input System，旧版 Input Manager 在跨设备适配上会更麻烦。

项目目录建议按下面的结构组织，重点是逻辑与资源分离、脚本按职责分层：

Assets/ Scenes/ Demo_AshCreek.unity Scripts/ Player/ PlayerMovement.cs GravityBody.cs Camera/ FollowCamera.cs System/ SlopeReporter.cs BuildScript.cs Prefabs/ Player/ Environment/ Settings/ PhysicsLayers.asset ProjectSettings/ Packages/

Scripts/Player放角色相关、Scripts/Camera放相机、Scripts/System放工具和构建脚本，这个分法看起来啰嗦，但当项目从 DEMO 长成正式项目时，你会庆幸当初分了。

3.1 物理层与碰撞矩阵的初始化

在写代码之前，先把物理层定下来。这一步经常被跳过，然后在排查“为什么射线打到了触发器”时浪费半天。打开 Edit > Project Settings > Tags and Layers，建立下面几个层：

Layer 8 : Player Layer 9 : Ground Layer 10 : Obstacle Layer 11 : Trigger

然后在 Physics 设置里把 Player 与 Trigger 的碰撞取消勾选。这个操作的意义是：射线检测可以直接用层掩码过滤，不用在代码里对每个命中做CompareTag判断，性能和可读性都更好。

4. 倾斜场景搭建的核心流程拆解

把“比萨斜楼”这类场景从零搭起来，可以拆成五步。每一步都有明确的产出物和常见坑，按顺序做能避免返工。

第一步，灰盒搭建。用 Cube 拼出楼层、楼梯、栏杆，不要一开始就上美术资源。灰盒阶段的判断标准只有一个：能不能走通。走到哪一步发现路线断了，立刻改，不要等到加了贴图再返工。灰盒阶段还要顺手把比例定下来，一层楼多高、角色多高、门多宽，这些数值后面改起来成本很高。

第二步，碰撞体整理。这是最容易出问题的一步。灰盒用的 Cube 自带 BoxCollider，直接能用；但一旦换成美术模型，碰撞体就需要重做。楼梯千万不要用 MeshCollider，角色控制器在复杂三角面上移动会卡顿甚至卡死，正确做法是用若干个 BoxCollider 拼出台阶。

第三步，角色控制器落地。这里要做的决策是：用 CharacterController 还是 Rigidbody？前者移动由代码驱动，可控性强、不会因为物理抖动而漂移；后者由物理引擎驱动，能自然地被撞击、被推动。DEMO 阶段如果不强调物理互动，优先 CharacterController，调试成本低得多。

第四步，重力与朝向对齐。角色站在水平面上时，向上方向就是世界坐标的 Y 轴；站在斜面上时，向上方向应该是地面法线。这一步不做，角色就永远是“斜着站”的，视觉上非常出戏。

第五步，相机与提示反馈。相机要能应对倾斜空间，角色进入倾斜区域时给玩家一个明确的视觉或文字提示。这一步在 DEMO 里经常被砍掉，但它是“玩家知不知道自己在干什么”的关键。

4.1 楼梯碰撞体的推荐做法

楼梯是斜楼场景里最容易被低估的部分。用 MeshCollider 的做法看起来最省事，但角色控制器在三角面拼接处会因为法线跳变而卡住，表现为“走到某级台阶就上不去”或者“脚底一直在抖”。

推荐做法是用一组 BoxCollider 拼出简化阶梯，每级台阶一个盒子，边缘略微重叠。这样法线是稳定朝上的，角色移动不会被打断。如果台阶数量很多，可以用一个斜面 BoxCollider 加一个坡度限制来替代视觉楼梯，玩家在视觉上看到台阶，实际碰撞走的是斜面。这种“视觉与碰撞分离”的做法在 DEMO 里很常见，成本低、体验损失小。

5. 核心代码实现：斜面上的角色控制

下面给出三个可以实际使用的脚本。它们的职责分别是：探测地面法线并让角色对齐、处理移动与重力、驱动相机跟随。三个脚本都挂在玩家对象上，或者由相机单独挂载。

5.1 重力对齐脚本

这个脚本做两件事：向上发射线探测脚下地面，把角色朝向平滑地对齐到地面法线。

// 文件路径：Assets/Scripts/Player/GravityBody.cs using UnityEngine; [RequireComponent(typeof(CharacterController))] public class GravityBody : MonoBehaviour { [Header("重力设置")] public float gravity = -9.81f; [Header("地面探测")] public LayerMask groundMask = ~0; public float probeDistance = 2.0f; public float probeOffset = 0.1f; [Header("对齐平滑")] public float alignSpeed = 12f; public bool alignToGround = true; private CharacterController controller; private Vector3 upDirection = Vector3.up; private Vector3 fallVelocity; public Vector3 UpDirection => upDirection; public Vector3 FallVelocity => fallVelocity; public bool IsGrounded { get; private set; } void Awake() { controller = GetComponent<CharacterController>(); } void Update() { ProbeGround(); ApplyGravity(); ApplyAlignment(); } private void ProbeGround() { Vector3 origin = transform.position + upDirection * probeOffset; Ray ray = new Ray(origin, -upDirection); if (Physics.Raycast(ray, out RaycastHit hit, probeDistance, groundMask, QueryTriggerInteraction.Ignore)) { IsGrounded = true; if (alignToGround) { upDirection = Vector3.Slerp(upDirection, hit.normal, alignSpeed * Time.deltaTime).normalized; } } else { IsGrounded = false; // 离开地面后逐渐回到世界向上方向，避免角色在空中保持倾斜 upDirection = Vector3.Slerp(upDirection, Vector3.up, alignSpeed * 0.5f * Time.deltaTime).normalized; } } private void ApplyGravity() { if (IsGrounded && fallVelocity.sqrMagnitude > 0f) { // 落地后把竖直速度清零，避免累积导致穿地 fallVelocity = Vector3.zero; } fallVelocity += upDirection * gravity * Time.deltaTime; controller.Move(fallVelocity * Time.deltaTime); } private void ApplyAlignment() { Quaternion targetRotation = Quaternion.FromToRotation(transform.up, upDirection) * transform.rotation; transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, alignSpeed * Time.deltaTime); } }

关键逻辑说明：射线起点抬高了probeOffset，是为了避免角色脚底刚好和地面重合时射线起点在地面内部导致检测失败。Vector3.Slerp而不是Lerp，是因为方向向量用球面插值在角度上更均匀，斜度大时不会出现一开端猛转、后面缓慢的情况。离开地面时让朝向慢慢回到世界向上，是为了避免角色跳起后在空中保持一个奇怪的倾斜姿态。

5.2 移动脚本

移动的核心难点在于：输入是二维的，但角色可能在任意朝向的平面上。直接用transform.forward会导致角色在斜面上越走越偏，正确做法是把输入方向投影到当前所在平面。

// 文件路径：Assets/Scripts/Player/PlayerMovement.cs using UnityEngine; #if ENABLE_INPUT_SYSTEM using UnityEngine.InputSystem; #endif [RequireComponent(typeof(CharacterController))] [RequireComponent(typeof(GravityBody))] public class PlayerMovement : MonoBehaviour { [Header("移动参数")] public float moveSpeed = 5.0f; public float sprintMultiplier = 1.6f; public float acceleration = 20f; public float rotationSpeed = 15f; [Header("坡度限制")] public float maxSlopeAngle = 50f; private CharacterController controller; private GravityBody gravityBody; private Vector3 currentVelocity; private Vector3 moveDirection; void Awake() { controller = GetComponent<CharacterController>(); gravityBody = GetComponent<GravityBody>(); } void Update() { ReadInput(out Vector2 input, out bool sprint); UpdateMoveDirection(input, sprint); ApplyMovement(); UpdateFacing(); } private void ReadInput(out Vector2 input, out bool sprint) { #if ENABLE_INPUT_SYSTEM Vector2 raw = Vector2.zero; if (Keyboard.current != null) { if (Keyboard.current.wKey.isPressed) raw.y += 1f; if (Keyboard.current.sKey.isPressed) raw.y -= 1f; if (Keyboard.current.dKey.isPressed) raw.x += 1f; if (Keyboard.current.aKey.isPressed) raw.x -= 1f; } input = Vector2.ClampMagnitude(raw, 1f); sprint = Keyboard.current != null && (Keyboard.current.leftShiftKey.isPressed || Keyboard.current.rightShiftKey.isPressed); #else input = new Vector2(Input.GetAxisRaw("Horizontal"), Input.GetAxisRaw("Vertical")); input = Vector2.ClampMagnitude(input, 1f); sprint = Input.GetKey(KeyCode.LeftShift) || Input.GetKey(KeyCode.RightShift); #endif } private void UpdateMoveDirection(Vector2 input, bool sprint) { Vector3 up = gravityBody.UpDirection; // 以角色当前朝向在平面上的投影作为前方基准 Vector3 forward = Vector3.ProjectOnPlane(transform.forward, up).normalized; if (forward.sqrMagnitude < 0.001f) { forward = Vector3.ProjectOnPlane(Vector3.forward, up).normalized; } Vector3 right = Vector3.Cross(up, forward).normalized; Vector3 desired = (forward * input.y + right * input.x); if (desired.sqrMagnitude > 1f) { desired.Normalize(); } float speed = moveSpeed * (sprint ? sprintMultiplier : 1f); // 检查前方坡度，超过限制就削减速度，模拟爬不上去 if (Physics.Raycast(transform.position + up * 0.5f, desired.normalized, out RaycastHit hit, 1.0f, gravityBody.groundMask, QueryTriggerInteraction.Ignore)) { float slope = Vector3.Angle(hit.normal, up); if (slope > maxSlopeAngle) { speed *= 0.2f; } } currentVelocity = Vector3.MoveTowards(currentVelocity, desired * speed, acceleration * Time.deltaTime); moveDirection = currentVelocity; } private void ApplyMovement() { controller.Move(moveDirection * Time.deltaTime); } private void UpdateFacing() { Vector3 flat = Vector3.ProjectOnPlane(moveDirection, gravityBody.UpDirection); if (flat.sqrMagnitude < 0.01f) return; Quaternion target = Quaternion.LookRotation(flat.normalized, gravityBody.UpDirection); transform.rotation = Quaternion.Slerp(transform.rotation, target, rotationSpeed * Time.deltaTime); } }

几个要点值得单独说。Vector3.ProjectOnPlane(transform.forward, up)这一步是必须的，因为角色的 forward 可能和地面不完全垂直，直接用它算右方向会得到长度不足 1 的向量，导致横向移动速度偏慢。坡度限制那段用射线探测前方一米内的法线角度，超过阈值就把速度压到 20%，这是最低成本的“爬不上去”表现，比一直滑下去更符合玩家预期。

5.3 相机跟随脚本

倾斜空间里相机的第一原则是：不要跟随角色的倾斜。角色的 up 会随地面变化，但相机的 up 必须永远是世界上方向，否则画面会跟着转，几秒钟就晕。

// 文件路径：Assets/Scripts/Camera/FollowCamera.cs using UnityEngine; public class FollowCamera : MonoBehaviour { [Header("跟随目标")] public Transform target; public Vector3 offset = new Vector3(0f, 2.2f, -4.5f); [Header("平滑")] public float positionSmoothTime = 0.12f; public float rotationSpeed = 8f; [Header("碰撞")] public LayerMask obstacleMask = ~0; public float cameraRadius = 0.3f; public float minDistance = 1.2f; private Vector3 velocity; void LateUpdate() { if (target == null) return; // 相机永远使用世界上方向作为 up，避免跟随角色倾斜 Quaternion targetRotation = Quaternion.LookRotation( target.position - transform.position, Vector3.up); Quaternion yawRotation = Quaternion.Euler(0f, targetRotation.eulerAngles.y, 0f); Vector3 desiredPosition = target.position + yawRotation * offset; // 球形投射检测相机与目标之间的遮挡，自动拉近 Vector3 dir = desiredPosition - target.position; float distance = dir.magnitude; if (Physics.SphereCast(target.position, cameraRadius, dir.normalized, out RaycastHit hit, distance, obstacleMask, QueryTriggerInteraction.Ignore)) { desiredPosition = target.position + dir.normalized * Mathf.Max(hit.distance, minDistance); } transform.position = Vector3.SmoothDamp(transform.position, desiredPosition, ref velocity, positionSmoothTime); transform.rotation = Quaternion.Slerp(transform.rotation, targetRotation, rotationSpeed * Time.deltaTime); } }

LateUpdate而不是Update，是为了保证相机在角色移动之后再计算位置，否则会出现一帧的延迟，表现为画面跟不上角色。Quaternion.Euler(0, yaw, 0)只保留水平旋转，去掉了俯仰，这是防止相机在斜面上仰视或俯视时姿态跟着倾斜的关键。SphereCast用一个有半径的球体代替射线，是因为单条射线会从墙角、栏杆缝隙里穿过去，导致相机卡进模型内部。

5.4 倾斜区域检测与提示

DEMO 里给玩家一个明确反馈很重要。下面这个脚本挂在倾斜区域对象上，检测玩家是否进入，并在地面角度超过阈值时触发提示。

// 文件路径：Assets/Scripts/System/SlopeReporter.cs using UnityEngine; using UnityEngine.Events; [RequireComponent(typeof(Collider))] public class SlopeReporter : MonoBehaviour { [Header("角度阈值")] public float warnAngle = 18f; [Header("事件")] public UnityEvent<float> onSlopeChanged; private Collider zoneCollider; void Awake() { zoneCollider = GetComponent<Collider>(); zoneCollider.isTrigger = true; } void OnTriggerStay(Collider other) { if (!other.CompareTag("Player")) return; Vector3 origin = other.transform.position + Vector3.up * 0.5f; if (Physics.Raycast(origin, Vector3.down, out RaycastHit hit, 3f, ~0, QueryTriggerInteraction.Ignore)) { float angle = Vector3.Angle(hit.normal, Vector3.up); onSlopeChanged?.Invoke(angle); if (angle > warnAngle) { Debug.Log($"[SlopeReporter] 玩家位于倾斜区域，当前坡度 {angle:F1} 度"); } } } }

注意zoneCollider.isTrigger = true在Awake里强制设置，而不是依赖面板勾选。这是为了避免团队成员拷贝对象时忘记勾选，导致角色被挡住。这类“在代码里兜底”的习惯在 DEMO 阶段很值得养成。

6. 打包、运行与效果验证

代码写完只是开始，能不能打出一个干净的包、别人机器上能不能跑，才是 DEMO 的真正验收标准。推荐用命令行打包，因为参数可以写进脚本，比手动点菜单更可靠、也更容易复现。

# 文件路径：Tools/build_windows.sh #!/usr/bin/env bash set -euo pipefail # Unity 可执行文件路径，请按实际安装位置修改 UNITY_PATH="${UNITY_PATH:-/Applications/Unity/Hub/Editor/LTS/Unity.app/Contents/MacOS/Unity}" PROJECT_PATH="$(cd "$(dirname "$0")/.." && pwd)" LOG_FILE="${PROJECT_PATH}/build.log" "${UNITY_PATH}" \ -batchmode \ -quit \ -nographics \ -projectPath "${PROJECT_PATH}" \ -executeMethod BuildScript.BuildWindows \ -logFile "${LOG_FILE}" echo "构建完成，日志：${LOG_FILE}"

配套的 Editor 脚本负责定义构建入口，注意必须放在Editor目录下，否则会参与运行时编译导致打包失败。

// 文件路径：Assets/Scripts/System/Editor/BuildScript.cs using UnityEditor; using UnityEditor.Build.Reporting; using UnityEngine; public static class BuildScript { private static readonly string[] Scenes = { "Assets/Scenes/Demo_AshCreek.unity" }; public static void BuildWindows() { BuildPlayerOptions options = new BuildPlayerOptions { scenes = Scenes, locationPathName = "Builds/Windows/AshCreekDemo.exe", target = BuildTarget.StandaloneWindows64, options = BuildOptions.None }; BuildReport report = BuildPipeline.BuildPlayer(options); BuildSummary summary = report.summary; if (summary.result == BuildResult.Succeeded) { Debug.Log($"构建成功，耗时 {summary.totalTime}，产物大小 {summary.totalSize} 字节"); EditorApplication.Exit(0); } else { Debug.LogError($"构建失败，结果：{summary.result}，错误数：{summary.totalErrors}"); EditorApplication.Exit(1); } } }

运行验证要分三层做，不能只在自己机器上跑一遍就认为完成。

第一层是编辑器内验证。开 Play 模式，走到斜面上，观察三件事：角色是否还保持竖直站立、相机画面是否跟着倾斜、在斜坡上松开按键角色是否会缓慢滑动。如果角色在斜面上原地抖动，先去查GravityBody的对齐速度是不是太快，alignSpeed调到 8 到 12 之间通常比较稳。

第二层是构建包验证。双击产物运行，用窗口模式跑，调整分辨率到 1280×720 和 1920×1080 各看一遍。重点关注 UI 是否错位、相机在窄长比例下是否把角色挤出画面。

第三层是异常场景验证。把窗口切走再切回来，看角色有没有卡在原地不动；拔掉手柄再插上；把帧率锁到 30 再跑一遍斜面。这三项是 DEMO 反馈里出现频率最高的问题来源。

如果运行失败，第一步应该看build.log，而不是先改代码。日志里搜error CS找编译错误，搜Build completed with a result of找构建结论，搜ArgumentException找资源引用的空引用。顺序对了，定位时间能砍掉一大半。

7. 常见问题与排查思路

下面这张表覆盖了倾斜场景 DEMO 中最高频的问题。排查顺序建议从上往下，因为前面的问题会掩盖后面的问题。

这张表里最值得展开的是“角色在斜面上抖动”。很多人第一反应是物理引擎精度不够，去调 Fixed Timestep，结果越调越乱。真实原因通常是两个：一是重力速度没有在落地时清零，导致每帧都在累加，角色被不断推向地面又被控制器推回来；二是朝向对齐的插值速度设得太快，角色旋转和地面法线在一帧内来回拉锯。把这两个问题分开验证，通常十分钟内能定位。

还有一个隐性问题是性能。斜楼场景如果用了大量独立的小物件做碰撞体，物理计算量会显著上升。定位方法是打开 Profiler，看Physics.Processing这一项的耗时占比，如果超过 3 毫秒就要考虑合并碰撞体或者用静态碰撞体。

8. 最佳实践与工程建议

关于 DEMO 阶段的工程习惯，我整理了几条在实际项目里最省事的。

第一条，所有可调参数外置。移动速度、重力大小、对齐速度、相机距离，全部做成public字段或者ScriptableObject，不要写死在代码里。DEMO 阶段策划和程序经常是同一个人，今天觉得手感刚好，明天改个模型尺寸就得全部重调，参数写死意味着每次都要改代码、等编译。

第二条，物理层要一次性定好。前面提到的 Player、Ground、Obstacle 分层，越早定越省事。后期再加层，意味着所有射线检测的掩码都要回头改一遍，漏改一处就是一个很难查的 bug。

第三条，异常输入要有兜底。窗口失焦时输入系统可能返回上一帧的值，导致角色一直往前跑；手柄热插拔可能导致输入设备索引变化。处理方式是在读取输入前判断设备是否存在，不存在就返回零向量，这比事后查“为什么角色自己会走”轻松得多。

第四条，版本管理要早立规矩。Unity 项目必须配.gitignore和.gitattributes，Library/、Temp/、Builds/不进仓库，*.fbx、*.png、*.wav走 LFS。这一步不做，等仓库涨到几个 G 再想补救，历史记录是清不掉的。

第五条，先做帧率预算再做内容。DEMO 阶段就该定下目标帧率，比如 60 帧，然后反推每帧 16.6 毫秒里，物理占多少、渲染占多少、脚本占多少。没有预算的优化都是瞎调，有了预算你就知道什么时候该停下。

第六条，给 DEMO 留一个应急退出路径。比如按 Esc 直接回到主菜单，或者提供一个“重置到检查点”的快捷键。试玩过程中玩家卡在某个位置出不来，是最伤体验的情况之一，而这个功能实现成本很低。

还有一点值得提醒：DEMO 发给别人之前，一定要在一台没有装过引擎的机器上跑一遍。开发机上装了各种运行时和依赖，很多缺失的库根本不会暴露。这一步能挡掉至少一半的“我这里打不开”的反馈。

9. 从这个 DEMO 场景能继续往下做什么

回到“比萨斜楼”这个场景，它真正的技术价值不在于画面有多特别，而在于它把一个常被忽略的问题摆到了台面上：当世界的“上”不再是固定的，你的角色控制、相机、输入映射、物理交互还能不能自洽。

这个问题往下延伸，会连带出不少值得深挖的方向。比如多重力源场景，玩家在不同重力区域之间切换时，朝向如何平滑过渡而不是瞬间翻转；比如在倾斜表面上做攀爬、滑行、贴墙移动，这些动作的状态机该怎么组织；再比如把整个角色控制抽成可配置的状态机，用数据描述不同地形下的移动参数，而不是在代码里写一堆 if。

如果你打算继续优化这套东西，建议的下一步是：先把手感跑顺，再考虑表现力。手感的核心指标就三个——加速和减速的曲线是否跟手、转身是否有惯性、在斜面上移动是否有明确的阻力反馈。这三个调好了，即使画面还是灰盒，玩起来也不会难受；反过来，画面再精致，手感飘忽，DEMO 也留不住人。

最后给一个实操建议：把这套脚本抽成一个可复用的角色控制器 Prefab，参数用ScriptableObject存成配置文件，下次开新 DEMO 直接拖进去改配置就行。DEMO 做多了你会发现，真正省时间的不是写代码快，而是上一版的代码不用重写。建议把这篇收藏起来，等下次在斜面上踩到坑的时候，直接照第 7 节那张表对一遍，比从头翻日志快得多。