UE4中基础的类及其之间的关系

最新推荐文章于 2023-07-04 10:12:40 发布

Anllyy

最新推荐文章于 2023-07-04 10:12:40 发布

阅读量1.9k

点赞数 2

CC 4.0 BY-SA版权

分类专栏： UE4 C++

本文链接：https://blog.csdn.net/qq_41363459/article/details/110501530

UE4 C++ 专栏收录该内容

22 篇文章

订阅专栏

想更详细深入的了解请点击这里

01 UObject

UObject 是所有Object的基类（不是所有类的基类），包含各类功能，诸如垃圾回收、通过元数据（UProperty）将变量公开给编辑器，以及保存和加载时的序列化功能。

UCLASS宏可用于标记从UObject派生的类，使UObject处理系统识别到它们。

02 AActor

AActor是所有Actor的基础类，AActor中有一个RootComponent成员，用来保存组件树中的顶级组件；

一个Actor若想被放进level中，就必须实例化USceneComponent * RootComponent，可以动态获取SceneComponent来当作RootComponent，在Actor里一一对应一个RootComponent；（Actor本身没有变换，所以不具有位置、旋转度或缩放比例信息，但是，它们可以依赖于他们组件的变换，更确切地讲，是它们的根组件。如果这个组件是 SceneComponent ，那么它将为该 Actor 提供变换信息。否则，Actor将没有变换。其他的附加组件的变换是相对于它们所附加到的组件的。）
AActor包含在AActor生命周期中调用的一系列事件。以下列表是一组简化的事件，描绘了整个生命周期。

BeginPlay——对象首次在Gameplay中存在时调用。

Tick——每帧调用一次，随着时间的进行持续完成工作。

EndPlay——对象离开Gameplay空间时调用。

03 UActorComponent

UActorComponent 是所有Component的基类，Component（组件）是一种特殊类型的对象，不可单独存在，旨在用作Actor中的子对象。
Component家族：

在这里插入图片描述

Actor和Component

ActorComponent不能互相嵌套，而在SceneComponent一级才可以嵌套；
Acto更像是一个容器，只提供了基本的创建、销毁、复制网络和触发事件等逻辑性的功能，而把父子的关系维护都交给了具体的Component。

04 APawn

APawn继承AActor，是分化出来的AActor，物理表示和基本的移动能力，他可以被player 或 AI拥有。

使用APawn需要包含头文件“GameFramework/Pawn.h”。

ADefaultPawn

因为我们每次想自己搞Pawn都得从Pawn派生过来，然后再一个个添加组件。UE知道我们大家都很懒，所以提供了一个默认的Pawn：DefaultPawn，默认带了一个DefaultPawnMovementComponent、spherical CollisionComponent和StaticMeshComponent。也是上述Pawn阐述过的三件套，只不过都是默认套餐。

ASpectatorPawn

UE的FPS做的太好了，就会有一些观众想要观战。观战的玩家们虽然也在当前地图里，但是我们并不需要真正的去表示它们，只要给他们一些摄像机“漫游”的能力。所以派生于DefaultPawn的SpectatorPawn提供了一个基本的USpectatorPawnMovement（不带重力漫游），并关闭了StaticMesh的显示，碰撞也设置到了“Spectator”通道。

ACharacter

因为我们是人，所以在游戏中，代入的角色大部分也都是人。大部分游戏中都会有用到人形的角色，既然如此，UE就为我们直接提供了一个人形的Pawn来让我们操纵。

ACharacter继承APawn。它是拥有mesh, collision 和内置移动逻辑的Pawn。它们负责玩家和AI和世界之间的所有物理交互，以及负责实现基本的网络和输入模型。它们通过使用CharacterMovementComponent来实现一个垂直朝向的可以在世界中走、跑跳、的玩家。飞、游泳。使用ACharacter需要包含头文件“GameFramework/Character.h”。

像人一样行走的CharacterMovementComponent，尽量贴合的CapsuleComponent，再加上骨骼上蒙皮的网格。同样的三件套，不一样的配方。

有些人一开始的时候会困惑应该选择Pawn还是Character，其实从继承体系中就可以了解到Character只不过是Pawn的加强特化版本。一般来说，如果你控制的角色是人形的带骨骼的，那就选择Character吧。而如果是VR中的一双手（假设只有一双手），因为移动模式和显示都算不太上人形，顶多只能算是个漂浮的“幽灵”，所以还是用Pawn方便些。后期如果你想加上人形模型和IK了，那么再把Mesh替换成SkeletalMesh也就行了。Pawn因为是基础款，所以提供了最大的灵活性。

05 AController

APlayerController和AAIController

关联Pawn的能力，有Possess和UnPossess，源码里也有PawnPendingDestroy等这些函数（未一一列出）；GameMode中也保存着AIControllerClass和PlayerControllerClass的配置，用于在适当的时候Spanw出Controller；继承于Actor也就有了EnableInput和Tick；Controller本身还可以继续派生下去（如AIController和PlayerController），也可以容纳Components；也带着一个SceneComponent所以可以摆放在世界中；自身也可以添加成员变量来记忆存储游戏状态；自身也有一个FName StateName（Playing、Spectating、Inactive），切换自身的状态（运行，观察，非激活）；因为跟Pawn是平级的关系，只在运行的时候引用关联，所以对彼此独立存在不做强制约束，提高了灵活性。

**既然Controller本身只是控制者，那它在场景中的位置和移动有什么意义吗？**Controller为何还需要个SceneComponent?意义在于如果Controller本身有位置信息，就可以利用该信息更好的控制Pawn的位置和移动。
首先说下Controller的Rotation，这个比较好理解一点，如果我想让我的Pawn和Controller保持旋转朝向一致，因为是Controller作主控制Pawn的关系，所以Controller就得维护自己的Rotation。再来说位置，如果Controller有自己的位置，这样在Respawn重新生成Pawn的时候，你就可以选择在当前位置创建。因此为了自动更新Controller的位置，UE还提供了一个bAttachToPawn的开关选项，默认是关闭的，UE不会自动的更新Controller的位置信息；而如果打开，就会把Controller附加到Pawn的子节点里面去，让Controller跟随Pawn来移动。你可以把这两种模式想象成一种是上帝视角在千里之外心电感应控制Pawn，另一种是骑在Pawn肩上来指挥。

对于PlayerController来说，因为玩家需要一个视角来观察世界，所以常常PlayerController常常会扛着个摄像机出现（蓝图里没有，但是会运行时生成PlayerCameraManager和CameraActor），所以就算没有角色可供操作，玩家也依然希望是可以视角漫游观察整个世界的（试试看把默认Level里的PlayerStart删掉后运行看看）。这个时候PlayerController常常会默认创建出一个ASpectatorPawn或者DefaultPawn（根据GameMode里配置），我们虽然看不见Pawn，但依然可以观察世界，靠得就是跟Controller关联的旋转和摄像机。

哪些逻辑应该写在Controller中？
如同当初我们在思考Actor和Component的逻辑划分一样，我们也得要划分哪些逻辑应该放在Pawn中，哪些应该放在Contrller中。上文我们也说过，Pawn也可以接收用户输入事件，所以其实只要你愿意，你甚至可以脱离Controller做一个特立独行的Pawn。那么在那些时候需要Controller？哪些逻辑应该由Controller掌管呢？可以从以下一些方面考虑：

从概念上，Pawn本身表示的是一个“能动”的概念，重点在于“能”。而Controller代表的是动到“哪里”的概念，重点在于“方向”。所以如果是一些Pawn本身固有的能力逻辑，如前进后退、播放动画、碰撞检测之类的就完全可以在Pawn内实现；而对于一些可替换的逻辑，或者智能决策的，就应该归Controller管辖。
从对应上来说，如果一个逻辑只属于某一类Pawn，那么其实你放进Pawn内也挺好。而如果一个逻辑可以应用于多个Pawn，那么放进Controller就可以组合应用了。举个例子，在战争游戏中，假设说有坦克和卡车两种战车（Pawn），只有坦克可以开炮，那么开炮这个功能你就可以直接实现在坦克Pawn上。而这两辆战车都有的自动寻找攻击目标功能，就可以实现在一个Controller里。
从存在性来说，Controller的生命期比Pawn要长一些，比如我们经常会实现的游戏中玩家死亡后复活的功能。Pawn死亡后，这个Pawn就被Destroy了，就算之后再Respawn创建出来一个新的，但是Pawn身上保存的变量状态都已经被重置了。所以对于那些需要在Pawn之外还要持续存在的逻辑和状态，放进Controller中是更好的选择。

最后是Actor、APawn和AController之间的关系：