创世记
UE创世，万物皆UObject，接着有Actor。
UObject:
起初，UE创世，有感于天地间C++原始之气一片混沌虚无，便撷取凝实一团C++之气，降下无边魔力，洒下秩序之光，便为这个世界生成了坚实的土壤UObject，并用UClass一一为此命名。
藉着UObject提供的元数据、反射生成、GC垃圾回收、序列化、编辑器可见，Class Default Object等，UE可以构建一个Object运行的世界。（后续会有一个大长篇深挖UObject）
Actor:
世界有了土壤之后，但还少了一些生动色彩，如果女娲造人一般，UE取一些UObject的泥巴，派生出了Actor。在UE眼中，整个世界从此了有了一个个生动的“演员”，众多的“演员”们，一起齐心协力为观众上演一场精彩的游戏。
脱胎自Object的Actor也多了一些本事：Replication（网络复制）,Spawn（生生死死），Tick(有了心跳)。
Actor无疑是UE中最重要的角色之一，组织庞大，最常见的有StaticMeshActor, CameraActor和 PlayerStartActor等。Actor之间还可以互相“嵌套”，拥有相对的“父子”关系。
Actor的概念在UE里其实不是某种具象化的3D世界里的对象，而是世界里的种种元素，用更泛化抽象的概念来看，小到一个个地上的石头，大到整个世界的运行规则，都是Actor.
Component:
世界纷繁复杂，光有一种Actor可不够，自然就需要有各种不同技能的Actor各司其职。在早期的远古时代，每个Actor拥有的技能都是与生俱有，只能父传子一代代的传下去。随着游戏世界的越来越绚丽，需要的技能变得越来越多和频繁改变，这样一组合，唯出身论的Actor数量们就开始爆炸了，而且一个个也越来越胖，最后连UE这样的神也管理不了了。终于，到了第4个纪元，UE窥得一丝隔壁平行宇宙Unity的天机。下定决心，让Actor们轻装上阵，只提供一些通用的基本生存能力，而把众多的“技能”抽象成了一个个“Component”并提供组装的接口，让Actor随用随组装，把自己武装成一个个专业能手。
Level
在UE的世界中，我们之前已经有了空气（C++）,土壤（UObject），物件（Actor）。而现在UE又施展神力创建了一片片大陆（Level），在这片大陆上（.map文件），Actor们秩序井然，各种地形拔地而起，植被繁茂，天空雾云缭绕，圣光普照，这也是玩家们降生开始精彩冒险的地方。
可以从ULevel的前缀U看出来Level（大陆）也确实是继承于UObject（土壤）的。那既然同属于Object下面的各Actor们都拥有了一定的智能能力（支持蓝图脚本），Level自然也得体现出大地的意志，所以默认带了一个土地公（ALevelScriptActor），允许我们在关卡里编写脚本，可以对本关卡里的所有Actor通过名字呼之则来，关卡蓝图实际上就代表着该片大陆上的运行规则。
在Level已经有了管理者之后，一开始大家都挺满意，但渐渐的就发现，好像各个Level需要的功能好像都差不多，都是修改一下光照，物理等一些属性。所以为了方便起见，UE便给每一个Level也都默认配了一个书记官（Info），他一一记录着本Level的各种规则属性，在UE需要的时候便负责相告。更重要的是，在Level需要有其他管理人员一起协助的时候，他也记录着“游戏模式”的名字来让UE可以指派
前面我们说过，有一些Actor是不“显示”的（没有SceneComponent），是不能“摆放”到Level里的，但是它依然可以在关卡里出力。其中一个家族系列就是AInfo和其之类。今天我们只简单介绍一下跟Level直接相关的一位书记官：AWorldSettings。
其实虽然名字叫做WorldSettings，但其实只是跟Level相关，我猜可能是在上古时代，当时整个世界只有一块大陆，人们就以为当前的大陆就是整个世界，所以给这块大陆的设置就起名为WorldSettings，后来等技术进步了，发现必须有其他大陆了，这个名字已经用得太多反而不好改了，就只好遗留下来了。当然也有可能是因为当Level被添加进World后，这个Level的Settings如果是主PersistentLevel，那它就会被当作整个World的WorldSettings。
注意，Actors里也保存着AWorldSettings和ALevelScriptActor的指针，所以Actors实际上确实是保存了所有Actor。
World
终于，到了把大陆们（Level）拼装起来的时候了。可以用SubLevel的方式：
Gameplay框架 游戏规则、玩家输出与控制、相机和用户界面等核心系统。 ——虚幻引擎4文档
1.框图:
GamePlay架构的后半部分就自底向上的逐一分析了各个层次的逻辑载体，按照MVC的思想，我们可以把整个游戏的GamePlay分为三大部分：表现（View）、逻辑（Controller）、数据（Model）。一图胜千言：
(1)UObject:
GC
MetaData
Reflection
Serialization
Editable Class Default Object
藉着UObject提供的元数据、反射生成、GC垃圾回收、序列化、编辑器可见，Class Default Object等，UE可以构建一个Object运行的世界
(2)Actor-演员/个体和Component-组件:
组成世界的单位
可以互相嵌套
组件的容器
可生成的
拥有Tick
网络通信的“通道”
注：不是所有Actor都看得见
Component-组件:
代表一种能力
为Actor提供能力
一般与业务逻辑无关
可跨游戏使用
(3)ULevel – 关卡和UWorld – 世界:
Actor的集合
构成World的版块
资源上对应*.umap
UWorld – 世界:
Level的集合
运行时真正的Actor集合
“关卡”的真正单位
场景的真正表示对象
(4)ALevelScriptActor-关卡蓝图:
特殊的默认脚本Actor
每个关卡一个
正经项目中应用场景有限
非常适用于原型项目或演示项目
适用于一些关卡本身的特定逻辑
(5)APawn-傀儡/棋子（兵卒/典当/质押）:
可被控制
采用MVC设计
“肉体”
(6)AController-控制器:
用来控制Pawn的Actor
“灵魂”
主角“灵魂”与真实玩家沟通的桥梁 真实玩家输入
AI“灵魂”与AI玩家沟通的桥梁 行为树+黑板+感知+EQS
APlayerState-玩家状态:
用于记录些啥
为了方便联机复制而抽离
(7)AGameMode – 游戏模式和AGameState – 游戏状态:
游戏规则”
世界的规则
最权威\
AGameState – 游戏状态:
世界的状态
可通过网络通知到各客户端
(8)UPlayer:
到了World这一层，整个游戏的渲染对象就齐全了。
但是游戏引擎并不只是渲染，因此为了让玩家也各种方式接入World中开始游戏。
GameInstance下不光保存着World，同时也存储着Player，有着LocalPlayer用于表示本地的玩家，也有NetConnection当作远端的连接。
玩家利用Player对象接入World之后，就可以开始控制Pawn和PlayerController的生成，有了附身的对象和摄像的眼睛。最后在Engine的Tick心跳脉搏驱动下开始一帧帧的逻辑更新和渲染。
(9)USaveGame – 保存游戏:
游戏存档
将此类的对象序列化保存到磁盘上来实现
(10)UGameInstance – 游戏实例:
个游戏的全局实例
World的外围管理对象
跨“关卡”的逻辑
3.整体类图
如果觉得《ue4的GamePlay框架》对你有帮助，请点赞、收藏，并留下你的观点哦！
