UnityStandardAsset工程、源码分析_6_第三人称场景[玩家控制]_工程组织

前言

在前几章（1-5），我们完整地分析了车辆场景，包括玩家控制和AI控制的全部机制。现在我们来分析StandardAsset里的下一个场景：第三人称场景

不过由于场景所用到的系统有很多是和车辆场景重复的，也就是说StandardAsset的各个场景共用一套包括输入系统在内的框架，所以我们对于接下来的场景的分析不会像车辆场景一样长达五章，我们仅分析每个场景内最特殊的部分，例如这个第三人称场景，我们将分析人物的控制逻辑，动画的播放等部分。
并且我反思了一下我在之前几章的分析过程中存在的问题，我决定先对场景的工程部分做彻底的分析，了解这个场景究竟做了些什么，实现了哪些功能，以及明晰游戏场景的组织结构，再根据这些结果结合代码去反推游戏实现的原理。而不是之前那样以代码作为分析入口，逐渐拼凑出游戏的架构，因为那样会导致我非常痛苦地边读边猜地过了一遍代码，却完全不知道这些运算有什么意义。采用这种新的自顶向下的方法可以大大提高我的分析速度。

---

第三人称场景

这两张动图展示了这个场景最主要的实现目标——人物控制：

• 奔跑
• 行走
• 跳跃
• 蹲伏
• 蹲伏前行
• 缓慢蹲伏前行
• 遇到狭小空间自动蹲伏

明确了目标，我们接下来分析工程的组织结构：

这是其中的一部分：

• GeometryStatic：场景中静态的部分
  
  它本身和GroundObstacles是空物体，下属的三个对象有自己的Mesh和MeshCollider：
  • GroundExtends：最大的那个圆盘，在它的边缘有一圈突起，用于防止玩家跑出场景。
  • GroundLines：场景中方形的区域，边缘的白色部分虽然是突起，高度却较低，可以被玩家跨越。
  • GroundObstacles：和父对象重名，但是是场景中间的白色复杂几何体，单独一个，而不是多个对象拼接而成，作为玩家的“攀爬架”或者说是行走跳跃的平台，玩家可以在这上面走走跳跳。
• GeometryDynamic：场景中动态的部分
  他的子物体BoxSmall就是那些动图中红色的盒子，拥有完全的物理效果，可以被玩家碰撞。
  Pickup比较特殊，是藏在攀爬架内的这个红色问号硬币：
  
  有Mesh和MeshCollider，但不同于BoxSmall的是，它没有刚体，也就是不能在碰撞后自由移动，也没有什么控制脚本，我不是很明白这个物体存在的意义。不过它名为Pickup，又是个硬币的形状，很可能是设定为可以在碰撞后被拾取的对象，就像索尼克里的金币一样，而开发人与因为某种原因放弃了这个物体的脚本开发工作，使这个物体则被不明不白地留在了场景中。
• Helpers：包含了两个系统
  • EventSystem：这是Unity原生的组件，我就不赘述了。
  • MainMenuLoader：这个物体上挂载的脚本会在游戏开始后，克隆一个MainMenuUI的预制件
    
    克隆后只显示右上角的Menu按钮，按下就可以显示中间的菜单栏，然后玩家可以通过这些选项来切换场景，或是前往learn.unity.com，这些脚本相对简单，这里也不再分析。
• UI：就是字面意义的UI
  其中的DualTouchControls是用于手机操作的一套交互UI，可以实现滑动来控制人物移动的功能，移动平台控制的部分我不太想分析，因为测试起来有点麻烦，大体也与键盘控制相同。
• Camera：摄像机
  很显然，其下属物体FreeLookCameraRig表示这个场景使用了自由摄像机来观察人物，上面的两张动图也可以看到，而自由摄像机的实现我在第四章分析过了，这里的实现完全相同，有需要请查阅第四章。
• Lights：灯光
  这个场景使用了两个平行光
  
  • LightMainDirectional：主要光源，ShadowType为SoftShadows，用于主要的场景照明和制造阴影。
  • LightFillDirectional：辅助光源，方向几乎与主光源相反，没有Shadow，仅给予一个蓝光，用于补光，照亮主光源照不到的部分。

---

上面这些分析是“其中的一部分”，那剩下的呢？剩下的当然是人物模型了：

如果有相关经验的话，应该立刻就能明白这下属的三个物体都是什么：

• EthanBody：人物的主要模型。
• EthanGlasses：人物的眼镜，就是这玩意：
  
  不是很懂为什么要分开，这个物体也没什么独立的动画。
• EthanSkeleton：骨骼对象，层数很复杂的节点。因为上面两个都是Mesh，使用了SkinMeshRenderer，而它们使用的骨骼集合就是这个EthanSkeleton。

这三个子物体没什么好说的，是通用的组织结构，而特殊的部分则在他们的父对象ThirdPersonController中，我们来看一下它的组件挂载情况：

• Transform：没什么好说的。
• Animator：这个人物的动画状态机，等下分析。
• Rigidbody：刚体组件，没什么好说的。
• CapsuleCollider：胶囊碰撞盒，人物的碰撞盒，在类人型对象中用的比较多，用来与场景内的其他碰撞体交互。
• ThirdPersonUserControl：用户输入接口，类似于赛车场景中的CarUserControl，用于读取原始的输入数据，并且调用ThirdPersonCharacter的Move方法。
• ThirdPersonCharacter：人物的核心控制逻辑，类似于CarController，用于更新人物的各类状态和设置Animator的参数。

这个场景中最重要的物体就是它，我们的分析也聚焦在这个物体的两个脚本上。不过这章我并不打算分析脚本，而是放在下一章。这章我们先来看看Animator这个组件，它接收了哪些数据，又怎么通过这些数据来播放动画。

---

Animator

• Controller：动画状态机，等会分析。
• Avatar：模型自带的Avatar，提供了一套类人的骨骼，可用于骨骼动画，与EthanSkeleton对应，具体的说明可以百度。
• ApplyRootMotion：根动画。在模型动画的制作过程中，可以定义模型的移动状态。例如一个人的跑步动画，它可以由美术人员来定义人物跑动的速度，也就是人物坐标的变化状况。否则奔跑动画只会包含跑步的动作，播放时人物会原地奔跑而不是前进。这里的Apply就是决定是否启用，不过这里设置成了Handled by Script，由脚本控制，也就是ThirdPersonCharacter，关于怎么控制，下一章分析。
• UpdateMode：动画的更新模式，有三种选项：
  • Normal：在Update内进行更新。
  • AnimatePhysics：在FixedUpdate内进行更新。
  • UnscaledTime：无视timescale进行更新，用于UI动画。
• CullingMode：剔除模式，用于表示在摄像机看不到的情况下的剔除原则，也有三种选项：
  • AlwaysAnimate：始终播放动画，不剔除。
  • CullUpdateTransforms：在摄像机看不到时不更新动画，但是根动画会更新。
  • CullCompletely：完全剔除，根动画也不更新。

看完了Animator组件，我们来看看之前提到的状态机Controller的结构：

• Airborne：在空中的动画。
  
  可以看到这个动画是一个混合树，由多个动画混合而成。有两个参数Jump和JumpLeg，用于在二维坐标上进行混合，这个机制的原理可以百度。这里说明一下这两个参数的意义：

  • Jump：人物速度在y轴上分量，映射到范围[-5,5]，人物在跳跃的时候，起跳、滞空、下落的动画是不同的，需要通过这个参数来混合。
  • JumpLeg：跳跃的起跳腿，因为用左脚起跳和用右脚起跳的动画也是不同的，用以决定该播放哪条腿的动画。

• Crouching：蹲伏的动画。
  

  • Turn：混合左右转向的动画，范围[-1,1]，负值为左转，正值为右转。
  • Forward：前进或停止，范围[0,1]，0为完全停止，1为最高速向前，中间值进行混合。

• Grounded：在地面上的一系列动画。
  
  在地面上的动画比较多，但是有规律，集合表示为：
  {原地，行走，奔跑} + {原地，行走，奔跑} X {左转，右转} X {普通，快速}
  一共15个动画，适用于不同的情况。它的参数和蹲伏的参数基本一致：

  • Turn：旋转的程度，范围[-1,1]
  • Forward：前进的程度，范围[0,1]

  通过这两个参数来混合动画。

---

总结

至此这个场景的工程结构就分析完了，并且我们明确了接下来的分析目标：

1. 弄清楚ThirdPersonUserControl是怎样处理输入数据的。
2. 分析ThirdPersonCharacter如何使用处理好的输入数据，如何更新人物对象的运动状态，如何计算出动画的参数并将其赋给Animator。

这些事情下一章来做。