《InsideUE4》GamePlay架构（七）GameMode和GameState

深入理解UE4

在探讨游戏玩法架构时，我们之前深入讨论了Actor层次结构，其中Controller作为APawn的逻辑控制者，而PlayerController和AIController则分别负责玩家输入和AI行动。现在，让我们继续探讨在Actor层次之上，UE4是如何控制Level这一更为宏观的层次的。

在游戏开发中，Level指的是游戏中的关卡概念。然而，对于游戏开发者来说，具体定义关卡并不总是显而易见的。从简单的《愤怒的小鸟》或《植物大战僵尸》到复杂的大型FPS游戏，再到《暗黑3》、《巫师3》乃至《无人深空》这样的游戏，如何定义和组织这些关卡？游戏行业为了更好地组织游戏逻辑和内容资源，发展出了不同的概念来理解和阐述，例如Cocos2dx中的Scene和Layer，Unity中的Scene，而UE4则将其视为World和Level的层次结构。

通过分析游戏机制，我们可以看出，“关卡”这一概念应当与“逻辑”和“表示”相区分。玩法构成了逻辑的核心，场景则承载着游戏的表示形式。因此，一个游戏由单一的玩法逻辑构成，但场景可以无限扩展，由多个表示构成。这意味着World包含Level，而不是反过来。这解释了为什么在UE4中，World更多地扮演逻辑概念的角色，而Level是资源场景的表示。

UE4的GameMode作为控制World业务逻辑的关键组件，它继承自AInfo家族，具有多种接口，主要分为几大块：

当一个World包含多个Level时，如何配置不同的GameMode？UE4在配置全局的GameModeClass之外，允许每个Level单独配置不同的GameModeClass。在由PersistentLevel和多个StreamingLevel组成的World中，尽管配置了不同的GameModeClass，但创建World时只会加载一次PersistentLevel，此时创建一个GameMode实例，后续加载StreamingLevel时不会动态创建新的GameMode，因此在任何时刻，World中只有一个GameMode实例。

Level迁移时，GameMode是否保持一致？当进行travelling（关卡切换）时，配置的GameModeClass不同，切换后使用的是哪个？在不开启bUseSeamlessTravel的情况下，切换时当前World和GameMode被释放，加载新的World并根据新的GameModeClass创建新的GameMode。若开启bUseSeamlessTravel，则切换过程更加复杂，GameMode会在中间过渡World中迁移，并在最终World中再次迁移，导致GameMode变化。

在GameMode与Level Blueprint之间，哪些逻辑应该位于哪一方？Level Blueprint通常用于定义场景的行为和表现，而GameMode则负责游戏逻辑的实现。如果需要在网络环境中同步状态，可以自定义GameState子类来存储GameMode运行过程中产生的数据。

UE4通过Actor分化派生的思想，实现了GameMode和GameState的解耦分离，支持玩法与表现的自由组合，并实现了网络状态的同步。此外，GameMode负责管理场景中的关键Pawn和Controller，关卡切换时处理特定的逻辑。

UE4在4.14版本中对GameMode和GameState进行了清理和优化，将基础逻辑抽离到AGameModeBase和AGameStateBase中，使开发者能够更轻松地实现简单的单机GameMode。

在游戏开发的旅程中，深入理解UE4的GamePlay架构对于构建复杂且高效的关卡和游戏逻辑至关重要。随着UE4的持续更新，开发者可以期待更多优化和改进，以便构建更加丰富和多样化的游戏体验。