UnrealEngine：GamePlay架构
一.文章简介UE提供的GamePlay框架，我们既然选择了用UE引擎，那么自然就应该想着怎么充分利用好它。框架就是你如果在它的规则下办事，那它就是事半功倍的助力器，你会常常发现UE怎么连这个也帮你做完了；而如果你在不了解的情况下想逆着它行事，就常常感受到怎么哪里都受到束缚。我们对于框架的理念应该就像是对待一辆汽车一般，我们关心的是怎么驾驶它到达想要的目的地，而不是折腾着怪它四个轮子不能按照你的心意朝不同方向乱转。 本篇文章旨在分享学习虚幻引擎GamePlay架构中遇到的好的文章，视频，问题解答，以及一些重点框架的个人理解，如果有不同意见欢迎指出。
二.基础架构
1.GamePlay基础架构构成
①.视频
UE甜筒#29.UE4虚幻引擎的的Gameplay框架—从Actor聊到GameInstance
[中文直播]第26期 | 虚幻引擎GamePlay框架理解与应用 | Epic 大钊 马骥
②.文章
《InsideUE4》系列:
（一）Actor和Component
（二）Level和World
（三）WorldContext，GameInstance，Engine
（四）Pawn
（五）Controller
（六）PlayerController和AIController
（七）GameMode和GameState
（八）Player
（九）GameInstance
（十）总结
（十一）Subsystems
2.网络模式中GamePlay基础架构相关
①.视频
彻底掌握UE4网络-02网络构架
②.文章
UE4-游戏框架—GameMode、GameState、PlayerState、Controller、Pawn
3.切换关卡中GamePlay基础架构相关
Ue4_无缝关卡切换与切换过程中游戏框架类生命周期
4.初始化中GamePlay基础架构相关
UE4初始化流程
三.扩展架构
GameplayAbilities（技能系统）、GameFeatures虽然都是作为插件在引擎中，但我个人认为其实它是也是属于Gameplay架构中的一部分，补充了游戏的技能系统以及玩法可拔插功能。
1.GameplayAbilities（GAS/技能系统）
①.视频
UE4 GAS入门00—初识技能
UE4 GAS入门01—初识AttributeSet和GameplayEffect
UE4 GAS入门02—初识GameplayCue
UE4 GAS入门03—GameplayEffect的Period和Stacking
UE4 GAS入门04—AttributeSet的持久化
UE4 GAS入门05—其它三种GE修改属性的计算方式
[中文直播]第31期｜GAS插件介绍（入门篇） | 伍德 大钊
深入GAS架构设计 | EpicGames 大钊
②.文章
GitHub - BillEliot/GASDocumentation ——GASDocumentation英文
GitHub - BillEliot/GASDocumentation_Chinese ——GASDocumentation中文
2.GameFeatures(通用的实现动态加载卸载游戏功能/实现玩法可拔插)
①.视频
虚怀若谷-模块化游戏功能框架 | Epic Games 大钊(官方字幕)
②.文章
《InsideUE5 GameFeatures架构系列》:
（一）发展由来
（二）基础用法
（三）初始化
（四）状态机
（五）AddComponents
（六）扩展和最佳实践（完结）
四.个人总结
1.基础架构问题
关于GamePlay架构的一些常见问题都在《InsideUE4》系列文章中有讲解，可以自行查看一下：
为何Actor不像GameObject一样自带Transform？
为何ActorComponent不能互相嵌套？而在SceneComponent一级才提供嵌套？
既然ALevelScriptActor也继承于AActor,为何关卡蓝图不设计能添加Component？
哪些逻辑应该写在Controller中？
哪些数据应该放在PlayerState中？
哪些逻辑应该放在PlayerController中？
哪些逻辑应该放在AIController中？
哪些逻辑应该写在GameMode里？哪些应该写在Level Blueprint里？
多个Level配置不同的GameMode时采用的是哪一个GameMode？
哪些逻辑应该放在GameInstance？
为什么要引进Subsystems？2.重点架构问题
①.ActorComponent、SubSystem、GameFeature、Plugins的区别
Ⅰ.ActorComponent : Actor级别的Component, 注重于功能能力，尽量与某款特定游戏无关，而与某类游戏相关，比如CharacterMovement, 依托Actor存在，封装基础功能，着眼于某一功能实现。
Ⅱ.SubSystem : GamePlay级别的Component,依托Gameplay对象存在，封装游戏的业务逻辑，专注于某部分游戏逻辑系统的调度安排。
Subsystem是GamePlay级别的Component。要好好理解这句话的关键是，你要明白：
Component组件模式在程序架构中的作用套路，组合胜过继承而带来的灵活性。
清晰区分通用功能和业务逻辑。对于一个游戏来说，通用功能可能是人物按格子行走的能力，而业务逻辑是这个人物自身的战斗结算系统。通常来说，我倾向于把功能理解为可在不同游戏之间复用的功能，尽量与某款特定游戏无关，而与某类游戏相关，比如CharacterMovement。那自然的，剩下的与某款游戏强相关的部分，就是该游戏的业务逻辑部分了。对于功能能力，你应该用ActorComponent来实现。对于业务逻辑，你应该用Subsystem来实现。更清晰的对比是：
ActorComponent：依托Actor存在，封装基础的功能，着眼于某一功能的实现。
Subsystem：依托GamePlay对象存在，封装游戏的业务逻辑，专注于某部分游戏逻辑系统的调度安排。
二者是配合补充的关系。Component在底层专注于功能，Subsystem在上层统筹调度。虽然二者也可以有一些交集，可以替代着实现一些功能，但笔者并不建议如此。Ⅲ.GameFeatures : 依赖于CoreGame（游戏本体）或其他GameFeature，注重于玩法，实现玩法可拔插，例如赛季活动更新。（一开始接触让我想到的是比如英雄联盟的无限火力、克隆模式，这种可以开启可以关闭的玩法。）
Ⅳ.Plugins : 不依赖于CoreGame（游戏本体）,且可能会各个项目复用的，注重于抽象。
------------------2023.2.7
页:
[1]