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里继承出来的。