GameMode控制着
1、Class登记
GameMode里登记了游戏里基本需要的信息
2、游戏内实体的Spawn
游戏的加载释放过程中产生的实体都是GameMode控制，包括Pawn，PlayerController，AIController等。
3、控制游戏的进度
GameMode里面又SetPause、ReStartPlayer等函数控制游戏暂停和重启
4、Level的切换
GameMode也决定了杠进入一场游戏是否播放开场动画等等
5、多人游戏的步调同步
在多人游戏时，我们常常需要等所有加入的玩家连上后，载入地图完毕后才能一起开始逻辑，UE提供了一个MatchState来指定一场游戏的运行状态，意义就是用一个状态机来标记开始和结束的状态。
一个Level对应一个GameMode实例
因此当有多个Level的时候，一定是PersistentLevel和多个StreamingLevel，这时就算它们配置了不同的GameModeClass，UE也只会为第一次创建World时加载PersistentLevel的时候创建GameMode，在后续的LoadStreamingLevel时候，并不会再动态创建出别的GameMode，所以GameMode从始至终只有一个，PersistentLevel的那个。
Level迁移时GameMode是否保持一致？
无论travelling采用哪种方式，当前的World都会被释放掉，然后加载创建新的World时
分两种情况：
不开启bUseSeamlessTravel，那么在travelling的时候（ServerTravel或ClientTravel），当前的World会被释放，所以当前的GameMode就被释放掉。新的World加载，就会根据新的GameModeClass创建新的GameMode。所以这时是不同的。
开启bUseSeamlessTravel，travelling时，当前World的GameMode会调用GetSeamlessTravelActorList：
哪些逻辑该写在GameMode里，哪些逻辑该写在Level Blueprint里？
GameMode更注重与逻辑的实现，比如游戏玩法（胜利条件，怪物刷新等），而Level Blueprint更注重本Level的表示逻辑，比如Level内某些Actor的运动轨迹，或者某一个区域的重力，或者触发一段特效或动画。
同Controller和Pawn一样的道理，一个GamePlay也可以应用到不同的Level中，所以通用的玩法是可以写在GamePlay里面的。
可以把GameMode之间协调工作交给GameInstance
PlayerState是用来保存玩家的游戏数据，那么同样的，对于一场游戏，也需要一个GameState来保存当前游戏的状态数据，跟PlayerState一样GameState也是从AInfo里继承出来的。