《InsideUE4》GamePlay架构学习_Pawn

Pawn

前言

本次系列是关于知乎InsideUE系列的学习记录。原作链接如下：原文链接

前面我们学习了大钊老师有关于Gameplay部分的各个层次内容。能理解UE的3D游戏世界是由Object->Actor+Component->Level->World->WorldContext->GameInstance->Engine来逐渐层层构建而成的。

接下来学习关于GamePlay部分的逻辑框架。

Note1：虽然本部分会涉及到游戏的业务逻辑编写部分，但并不打算详细讨论AI（BehaviorTree，Navigation等）。AI也是一个很大的话题，值得专门开个大章节讨论，我们现在不应该委屈她。
Note2：本部分也不会细讨论输入事件的处理，游戏逻辑确实一大部分是由输入事件驱动起来的，不过我们此时只是简单聊一下概念，后续会有章节再细讨论输入事件的路由流程。
Note3：联机游戏的游戏逻辑自然也是非常重要的，但为了简化本章节的概念，所以网络联机的逻辑同步等也都不会涉及。留待后续网络章节再好好的阐述。

Component

由之前的学习，Actor可以理解成一个小的容器，用来装进不同Components的功能，甚至能嵌套不同Actor的功能。

正确理解“功能”和“游戏业务逻辑”的区分是理解Component的关键要点。

有关于游戏业务逻辑应该是针对与特定游戏的特殊功能或是特殊规则，而功能应该是能够无痛迁移到其他项目的。

Component应该是功能的载体。

Actor

那么我的游戏逻辑要放在哪呢？

在Unity中，由于我们的Script都是以组件的形式放在物体身上，所以实际上逻辑都是在组件层运行的。这其中就包括了游戏的业务逻辑，只不过对于这些逻辑我们可能会采取一些设计模式来进行管理，比如我们通过自建的GameController对全局进行一些管理。

那么在UE中，上面强调了Components应该是综合了“功能”的概念，在看UE源码时，你会发现UE用了大量的继承，在这些里 ，UE特化了Pawn和Character，以及各种Controller来完成游戏逻辑。

Pawn

游戏中可能存在大量的Actors，在这些角色中，大部分是Level中静态的或者是自行运转的，可能只有少部分是能与玩家进行交互的。如与NPS的互动对话、特殊物品的按键交互。

于是 Pawn 应运而生，派生