《InsideUE4》GamePlay架构学习_Actor与Componet

Actor与Componet

前话

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

Unity To UE4

在Unity的世界里，存在一个世界空间，空间中的最基础的东西就是 GameObject（物体）。物体拥有最基础的 Transform（变换）组件以及Mono有关的功能，我们称该功能为 Component（组件）。在不同组件有着不同功能的概念下，我们通过在不同物体上添加不同的组件来创造一个我们想要的游戏世界。

那么UE4是怎么什么实现这方面的功能呢？

在UnrealEngine中，首先最基础最底层的就是 UObject ，UObject主要提供跟类以及引擎有关的工作：

GC垃圾回收、反射、元数据、序列化、编辑器可见、Class Default Object等等。

可以说这是一个抽象的概念。而将其具象化到游戏场景的是AActor(Actor)。Actor类似于Unity中的GameObject，但又不完全一样。它可以表示一个具体的物体如：方块、人等，也能用来表示一些抽象但存在的元素，代表世界中的某种规则或者信息表示，如AInfo(派生类AWorldSetting,AGameMode,AGameSession,APlayerState,AGameState等)，AHUD,APlayerCameraManager等。因此对于Actor来说,Transform不是必须的组件。

如UE为我们自动编辑的AGameModeBase类文件，并不需要放进场景可供我们观察到，但在运行时会执行我们放在里面的一些规则。

经过了UE的权衡和考虑，把Transform封装进了SceneComponent,当作RootComponent。但在权衡到使用的便利性的时候，大部分Actor其实是有Transform的，我们能通过一些API来获取。

跟Unity一样，有了单一Actor之后，就需要UActorComponent来扩充Actor的能力。不同组件有不同功能，通过将其连接到Actor来给其添加不同的功能模块。

思考

Actor和Component的关系

Actor更像一个容器，在这容器下包含着不同的Components。感觉Unity组件是彻底“融入”物体，而UE更像是挂在Actor身上。

下图是最常见的一些Component成员。

为何ActorComponent不能互相嵌套？而在SceneComponent一级才提供嵌套？

如下图：

因为两者各有好处，这里直接引用原文作者的话：

老实说，如果让我来设计Entity-Component模式，我很可能会为了通用性而在ActorComponent这一级直接提供嵌套，这样所有的Component就与生俱来拥有了组合其他Component的能力，灵活性大大提高。但游戏引擎的设计必然也经过了各种权衡，虽然说架构上显得并不那么的统一干净，但其实也大大减少了被误用的机会。实体组件模式推崇的“组合优于继承”的概念确实很强大，但其实同时也带来了一些问题，如Component之间如何互相依赖，如何互相通信，嵌套过深导致的接口便利损失和性能损耗，真正一个让你随便嵌套的组件模式可能会在使用上更容易出问题。

SceneComponent哲学

UE注重于让各个部分（不同SceneComponent）完成好不同的功能，然后在放在一个盒子（Actor）下运行；而不是在Actor上（直接对Actor编码）去统一操作各个部分（各个部分只具有抽象出来的最基本的功能，如位置变换等等。）