架构学习

AActor

首先是继承自UObject的AActor，它代表着游戏中的种种表示，不只是游戏物体对象这种概念，而且囊括了GameMode,GameState等这些属于游戏机制游戏规则的灵体AActor，这些存在与游戏世界中，但是却没有具体的空间表示，因此对于UE4中Actor不像Game Object一样自带Transform。

UE4同样也是使用一种实体组件的模式，即ECS模式，“组合优于继承"，但是多component的组合会产生一些组件通信，耦合依赖过深导致的接口便利损失，而且在UE4的逻辑中，是不希望我们的游戏逻辑写在component里面的，因此component的功能很独立单一。

UE4非常强调的一点就是表现层和逻辑层分离，因此对于一个多component的Actor来说，所有的这些Component都融合进了一个整体的Actor，这个Actor就是一个封装的盒子，而在这个盒子的内部，就可以做一些针对component的相关逻辑操作。

ULevel

level的概念其实同unity 的scene概念类似 ，就是一个世界表示，但是UE4会考虑到资源加载的玩家可见范围优化，因此level是更细粒度的世界表示，更高一层是world，由各个level组成。

level是自带一个关卡蓝图ALevelScriptActor的，我们可以在里面获取整个关卡的相关信息，同时由于各个关卡的一些规则属性不同，因此衍生出一个world setting来记录，这个world并非之前说的大的world属性，而是针对我们的一个个小的level的设置的。

关卡蓝图准确的说也是一个Actor，但是我们在实际的蓝图界面中却看不见有component添加的选项卡，这只是UE4引擎给我们的一个提醒，不希望我们在关卡蓝图中复杂话它的组件构成，即添加组件，但是在实际中其实我们是可以通过蓝图连线接口Add Component来添加组件的，但是这是不好的，复杂化关卡构成会对整体游戏的Actor逻辑产生影响，因为level是包含世界中的Actor的，而具体的Actor势必会存在各种组件，这些组件或许会迷惑分不清是关卡组件还是游戏对象组件。还是那种说法，逻辑与表现分开，其实UE4也已经帮我们做好的逻辑的分离，Game Mode，Game Controll其实就是针对具体level的逻辑控制Actor。

world是一种level的集合，提供一种level动态加载的方法，但是在world加载的时候总是会有一个persistentLevel来初始化世界的.

world的概念不是那么简单的，不只是我们理解的游戏世界，首先World就不是只有一种类型，比如编辑器本身就也是一个World，里面显示的游戏场景也是一个World，这两个World互相协作构成了我们的编辑体验。然后点播放的时候，引擎又可以生成新的类型World来让我们测试。

游戏逻辑的承载，Pawn和Controll

对于unity，由于组合思想，引擎将游戏逻辑也作为一个组合体放在游戏对象中，作为一个ScriptComponent来承载游戏的逻辑，但是这样的话，是由一个component来管理其他的component，这种同层级别的管理其实是不太好的。

对于游戏中的游戏对象，有些是需要由逻辑控制的，在世界中是动态的，但是有些对象在世界中只是作为一种表示，而没有具体的移动和逻辑控制，因此它是不需要进行附加逻辑的。对于那些动态的对象，玩家需要控制的对象，UE4继承分割出Pawn，更深层次是Character。

对于Pawn而言，它实现的是响应控制，”可被控制“，对于按键操作之后是按键响应，而在按键之后，如何移动就是一个简单的move操作，这就是输入响应的结果，而对于逻辑控制则是更高层的行为，比如寻路或者其他的逻辑。

对于Pawn和Controll的对应关系，UE4的限定是1：1的对应关系，当然也能够实现一对多，但是这种多个关系的维护会对控制者的逻辑和性能有一定的混乱和影响。

对于Controll的逻辑信息，Pawn表示的是能进行操作，controll决定的是怎样进行操作。同时，controll的生命周期是比pawn长的，因为在实际游戏中会存在玩家死亡复活的情况，复活后的controll是不需要变化的，同时还要维护新的pawn的状态，因此它的生命周期要长。