UE4 初学者入门笔记（一）

GameInstance

游戏实例，自始至终存在，不依赖于关卡。一般而言，一个游戏只有一个GameInstance，但是对于UE4而言，UE4不仅要面对游戏，还要面对编辑器，甚至是辅助程序，所以Engine可以管理多个GameInstance就像一个资源可以开启多个实例：

言归正传，因为UE的这套Editor自绘机制，还有PIE（PlayInEditor），进程里其实是可以同时有多个GameInstance的，如正在编辑的EditorWorld所属于的，和Play之后的World属于的。我想，这也就是为何UE把它叫做GameInstance而不是简单的Game的含义，其名字中就隐含了多个Instance的深意。
——《InsideUE4》GamePlay架构（九）GameInstancesu

哪些逻辑可以放在GameInstance中：
1.关卡的切换
2.players
3.UI的管理
4.全局配置

5.游戏的第三方逻辑

如果你的游戏需要其他一些控制，比如自己写的网络通信、自定义的配置文件或者自己的一些程序算法，如果简单的话，GameInstance也可以一放，等复杂起来了，也可以把GameInstance当作一个模块容器，你可以在里面再扩展出来其他的子逻辑模块。当然如果是插件的话，还是在自己的插件Module里面自行管理逻辑，然后把协调工作交给GameInstance来做。

PlayerController

玩家直接控制的实体，跟玩家直接相关的操作很多都委托它来完成，相当于游戏内的一个“玩家实体”。一个PlayerController可以拥有一个Pawn/Character,关系就像lol中的召唤师与英雄一样。

在PlayerController中，大概包含：
1.Camera管理
包含了一个PlayerCameraManager类对象，用来方便的切换相机。
2.Input系统
3.UPlayer关联
和Player对应起来，一个PlayerController只有在SerPlayer之后，才能开始工作
4.HUD
5.Level的切换
6.Voice
为了方便网络中语音聊天的一些控制函数

UE的思想是具象化一个“玩家实体”，并把所有的跟该玩家相关的操作和接口都交给它完成。一般其他的游戏引擎只是个“功能引擎”，提供了一些图形渲染UI系统等组件，但是在GamePlay这个层次就都非常欠缺了，一般都需要开发者自己搭建一套。而回想你写过的游戏，是不是也往往有一个Player类（一般是单件或者全局变量）？里面几乎是放着所有跟该玩家相关的业务逻辑代码。UE里的PlayerController就是这种概念，优点当然是直接方便好理解，缺点也如你所见，会代码膨胀得比较快。不过目前来说还算能接受，等某一块功能真的比较大了之后，可以再把它抽出一个单独的类来，如PlayerInput和PlayerCameraManager一样。
——《InsideUE4》GamePlay架构（六）PlayerController和AIController

注：PlayerController是可以被替换的，比如马里奥在水下的控制方式就明显与平时不同，所以不能像"Player"一样什么都放进去，一旦被替换数据将丢失