UnrealEngine：GamePlay架构

      UE提供的GamePlay框架，我们既然选择了用UE引擎，那么自然就应该想着怎么充分利用好它。框架就是你如果在它的规则下办事，那它就是事半功倍的助力器，你会常常发现UE怎么连这个也帮你做完了；而如果你在不了解的情况下想逆着它行事，就常常感受到怎么哪里都受到束缚。我们对于框架的理念应该就像是对待一辆汽车一般，我们关心的是怎么驾驶它到达想要的目的地，而不是折腾着怪它四个轮子不能按照你的心意朝不同方向乱转。

为何Actor不像GameObject一样自带Transform？
为何ActorComponent不能互相嵌套？而在SceneComponent一级才提供嵌套？
既然ALevelScriptActor也继承于AActor,为何关卡蓝图不设计能添加Component？
哪些逻辑应该写在Controller中？
哪些数据应该放在PlayerState中？
哪些逻辑应该放在PlayerController中？
哪些逻辑应该放在AIController中？
哪些逻辑应该写在GameMode里？哪些应该写在Level Blueprint里？
多个Level配置不同的GameMode时采用的是哪一个GameMode？
哪些逻辑应该放在GameInstance？
为什么要引进Subsystems？

Subsystem是GamePlay级别的Component。要好好理解这句话的关键是，你要明白：
Component组件模式在程序架构中的作用套路，组合胜过继承而带来的灵活性。
清晰区分通用功能和业务逻辑。对于一个游戏来说，通用功能可能是人物按格子行走的能力，而业务逻辑是这个人物自身的战斗结算系统。通常来说，我倾向于把功能理解为可在不同游戏之间复用的功能，尽量与某款特定游戏无关，而与某类游戏相关，比如CharacterMovement。那自然的，剩下的与某款游戏强相关的部分，就是该游戏的业务逻辑部分了。对于功能能力，你应该用ActorComponent来实现。对于业务逻辑，你应该用Subsystem来实现。更清晰的对比是：
ActorComponent：依托Actor存在，封装基础的功能，着眼于某一功能的实现。
Subsystem：依托GamePlay对象存在，封装游戏的业务逻辑，专注于某部分游戏逻辑系统的调度安排。
二者是配合补充的关系。Component在底层专注于功能，Subsystem在上层统筹调度。虽然二者也可以有一些交集，可以替代着实现一些功能，但笔者并不建议如此。