1. 项目概述如果你用UE4蓝图做过项目尤其是稍微复杂点的肯定遇到过这种场景角色血量管理、UI更新、敌人AI、场景交互的代码全挤在一个角色蓝图里改个攻击力都得小心翼翼生怕牵一发而动全身。或者你和队友同时修改一个蓝图合并冲突时恨不得把电脑砸了。这背后的根源往往不是蓝图语法不熟而是对UE4 GamePlay框架里那几个核心“角色”——GameMode、PlayerController、Pawn、Character、GameState、PlayerState——到底该干什么、怎么互相“说话”没整明白。理解每个角色的职责边界和它们之间的协作方式是让你的游戏从“能跑起来”到“健壮、可扩展、易于协作开发”的关键一步。这篇文章我们就抛开枯燥的概念罗列直接从一个具体的多人协作射击游戏原型案例出发拆解这些核心角色如何各司其职并通过蓝图节点清晰地“握手”协作。我会分享在实际项目中踩过的坑比如为什么不该在Character里直接处理得分逻辑以及如何利用事件分发器Event Dispatcher和接口Interface实现低耦合的通信让你们的项目蓝图结构清晰得像教科书。2. GamePlay框架核心角色职责深度解析2.1 导演与规则制定者GameMode与GameState你可以把GameMode理解为剧组的导演兼编剧它只在服务器端存在决定了这场“戏”的基本规则和流程。它的核心职责是生成其他角色比如默认的Pawn和PlayerController类管理游戏状态如等待玩家、进行中、结束并定义游戏规则如获胜条件、回合制逻辑。一个常见的误区是把随时间变化的数据比如剩余时间、团队总分放在GameMode里。GameMode是规则的制定者不是数据的记录员。这些需要同步给所有客户端的数据应该交给GameState。GameState就像是剧组里的场记板负责记录和广播当前这场“戏”的全局状态。它在服务器和所有客户端上都存在服务器是权威版本客户端是复制过来的副本。所有玩家都需要知道的全局信息比如游戏已进行时间、当前比分、存活玩家列表都应该放在GameState里。这样做的好处是任何客户端都可以直接从GameState获取这些信息无需向服务器频繁请求。实操心得在蓝图里GameMode的设置是在项目设置里的“Maps Modes”中指定。而GameState的属性如果你希望客户端能实时看到变化务必勾选“Replication”复制。例如定义一个“TeamAScore”整数变量勾选“Replicated”那么当服务器修改它时所有客户端的UI都能自动更新。2.2 玩家的化身与大脑Pawn、Character与PlayerController这是最容易混淆的一组概念。Pawn是玩家或AI在游戏世界中的物理化身可以理解为演员的“身体”。它拥有位置、旋转可以被控制。Character是Pawn的一个子类UE4贴心地为它内置了一个胶囊体碰撞组件和一套基于角色的移动组件Character Movement Component所以对于需要行走、跑跳、游泳等标准人类移动的游戏角色直接使用Character是最方便的。那么谁来控制这个“身体”呢就是PlayerController。它是玩家的“大脑”负责处理玩家的输入鼠标点击、键盘按键并将这些输入转化为对Pawn的控制命令。一个PlayerController通常只控制一个Pawn。它也是处理玩家专属逻辑的好地方比如管理玩家的输入模式UI模式还是游戏模式、处理相机切换、以及持有PlayerState。重要边界Character蓝图里应该主要包含与这个“身体”直接相关的逻辑移动、动画状态机、受击反应、装备附着点。而像“按下E键与门交互”这种输入检测逻辑应该放在PlayerController里由它判断按下E键后再通过接口调用门上的交互函数。这样当你需要更换角色模型换一个Pawn时交互逻辑不需要重写。2.3 玩家的私人档案PlayerStatePlayerState是伴随玩家整个游戏会话的“私人档案”同样存在于服务器和客户端。它用于存储玩家个体的状态数据比如玩家名称、个人得分、杀敌/死亡数、装备情况等。它与PlayerController的生命周期不同——PlayerController在玩家退出游戏时就被销毁了而PlayerState在玩家离开后可能还会短暂存在例如在积分榜上显示直到被清理。为什么个人得分不放在Character里因为Character会死亡、会重生。如果得分存在Character上角色一死得分就清零了这显然不合理。PlayerState才是存储这类持久性个人数据的正确位置。注意事项PlayerState的复制也是默认开启的但要注意性能。不要每一帧都去修改PlayerState里的变量并复制这会产生大量网络流量。通常是在事件发生时如得分、拾取物品才去更新。3. 基于实例的蓝图协作流程拆解我们以一个简单的“团队夺旗”游戏原型为例拆解上述角色如何协作。游戏规则两张地图中央有一面旗子。玩家分为红蓝两队需要夺取敌方旗子并带回己方基地得分。3.1 游戏初始化与角色生成流程GameMode 设置在项目设置中我们指定了自定义的BP_TeamDeathMatchGameMode。在其Event BeginPlay事件中我们设置游戏初始状态如GameState中的RemainingTime300秒并调用SpawnDefaultPawnFor函数为每个连接的玩家生成默认角色BP_TeamCharacter。PlayerController 的接管当玩家客户端加入时服务器会为其创建一个BP_TeamPlayerController实例。GameMode通过PostLogin事件通知有新玩家加入并可以将这个PlayerController与生成的Pawn进行绑定Possess。Character 与 PlayerState 的关联生成的BP_TeamCharacter在BeginPlay时需要知道自己的队伍颜色。它可以通过Get Player State节点获取到属于自己的BP_TeamPlayerState然后从中读取TeamColor变量并据此设置自身材质如红色或蓝色。这个过程通常在服务器端完成然后Character的外观复制到客户端。关键蓝图节点Get Game Mode在任何蓝图中获取当前游戏的GameMode实例。Get Player Controller在Character或HUD蓝图中获取控制它的玩家控制器。Get Player State在Character或PlayerController中获取关联的PlayerState。Cast To类型转换节点至关重要。当你通过上述节点获取到一个通用对象后需要将其转换为你自定义的蓝图类如Cast to BP_TeamPlayerState才能访问其中自定义的变量和函数。3.2 游戏进行中的跨角色通信核心场景红队玩家A夺取了蓝队旗子。事件触发CharacterBP_TeamCharacter与旗子一个Actor发生重叠事件。在旗子的蓝图里检测到重叠的Actor是Character并且通过接口调用确认该Character属于红队。状态变更与通知GameState旗子Actor不应该直接修改分数。它应该触发一个自定义事件比如OnFlagPickedUp并将夺取者的PlayerState作为参数。这个事件的逻辑应该在GameMode或一个专门的管理器比如BP_GameplayManager中监听。这里我们选择在GameMode中处理GameMode监听到事件后首先修改GameState中的全局状态变量例如bBlueFlagTaken true。然后它需要广播这个事件给所有相关方。事件分发Event Dispatcher为了解耦我们在GameState上创建一个Event Dispatcher命名为OnTeamScoreChanged。当GameMode修改了分数后它调用GameState上的一个函数UpdateTeamScore(RedTeam)在这个函数内部除了更新RedTeamScore变量还会Call那个OnTeamScoreChanged事件分发器。多方响应UI更新所有玩家的HUD蓝图或Widget组件在游戏开始时就Bind绑定了GameState的OnTeamScoreChanged事件。当事件被调用时UI自动更新比分显示。音效与提示PlayerController也可以绑定这个事件当自己队伍得分时在客户端本地播放一个欢呼音效和屏幕提示。旗子状态重置GameMode在处理得分后还会调用一个函数来重置旗子的位置和状态。这个流程的优势Character只负责触发“夺旗”这个动作GameMode负责裁决和更新核心规则数据GameState负责存储和广播状态变化UI和其他系统只负责监听和反应。任何一环需要修改比如改变计分规则或UI样式都不会影响其他环节。3.3 使用接口实现灵活交互在上面的例子中旗子需要判断重叠的Actor是否属于某个队伍。我们不应该让旗子蓝图直接去Cast To BP_TeamCharacter因为未来可能有其他类型的Pawn也能夺旗比如车辆。更好的做法是使用接口。创建接口创建一个名为Teamable的蓝图接口里面添加一个函数GetTeamColor返回一个枚举值红队、蓝队。实现接口让BP_TeamCharacter和任何可能需要区分队伍的蓝图都实现这个接口。在BP_TeamCharacter的GetTeamColor函数实现里返回从自身PlayerState中读取的队伍颜色。调用接口在旗子的重叠事件中不再进行类型转换而是使用Does implement interface?节点检查重叠的Actor是否实现了Teamable接口。如果是则调用接口函数GetTeamColor来获取队伍信息。这样做旗子完全不需要知道是谁在跟它交互它只认“接口”。未来增加新的可夺旗单位只需要让新单位实现Teamable接口即可旗子蓝图一行代码都不用改。4. 蓝图协作中的常见陷阱与最佳实践4.1 网络复制Replication的坑网络游戏是蓝图协作的试金石。最常见的坑就是忘了设置复制或者复制了不该复制的东西。该复制没复制GameState里的比分、PlayerState里的个人数据、Character的外观状态如是否持旗这些需要所有客户端看到一致状态的变量必须勾选“Replicated”。忘记勾选的结果就是只有服务器能看到变化其他玩家眼里游戏状态是错的。不该复制的乱复制每一帧都在变化的变量如角色的精确位置和旋转由UE4的移动组件自动处理或者只在本地客户端需要的变量如某个特效的播放状态如果手动复制会增加不必要的网络负担。计算密集的函数也不要在客户端调用Run on Server节点过于频繁。复制回调函数当一个复制变量值发生变化时你可以在其后的“Replication”下拉框中选择“RepNotify”。这会生成一个OnRep_[变量名]事件。这个事件在客户端变量更新时触发但在服务器端不触发。常用来在客户端更新UI或播放效果。例如在PlayerState中设置Kills变量为“RepNotify”当Kills增加时在客户端的OnRep_Kills函数里更新屏幕上的击杀数文本。4.2 引用管理与空指针防护蓝图之间通过引用进行通信。获取引用失败返回null是运行时错误的常见原因。安全的引用获取流程使用Get Game State、Get Player Controller等节点获取对象引用。立即用一个Is Valid节点检查引用是否有效。如果有效再进行Cast To转换。转换后可以再用一个Is Valid检查转换后的对象虽然通常不需要但更保险。典型场景在Character的BeginPlay事件中获取PlayerState。如果这个Character是由AI控制的没有PlayerState那么Get Player State会返回空。你的后续逻辑如设置队伍颜色就必须放在Is Valid为真的分支里否则游戏会崩溃。4.3 输入处理的层级输入处理应严格遵循层级PlayerController 优先将核心的游戏操作移动、跳跃、射击、交互的输入事件绑定在PlayerController蓝图中。PlayerController是输入的“第一接收者”。Pawn/Character 执行在PlayerController的输入事件里调用其当前控制的Pawn或Character上的函数来执行具体动作。例如PlayerController中的“Jump”输入事件调用Controlled Pawn上的Jump函数。UI输入分离当打开菜单时你需要切换输入模式。UE4提供了Set Input Mode节点在PlayerController中。可以设置为“UI Only”仅UI或“Game and UI”游戏和UI。确保UI控件如按钮的点击不会意外触发游戏角色的动作。实操心得对于多人游戏记住一个黄金法则凡是影响游戏核心规则和状态的决定性逻辑必须在服务器端的权威蓝图中执行。客户端只能发起请求通过Run on Server节点和表现效果。例如扣血计算必须在服务器的Character蓝图里进行然后通过复制将血量同步到客户端。客户端只能播放受击动画和屏幕特效。5. 大型项目中的蓝图架构扩展建议当项目规模变大仅靠GamePlay框架的基础角色可能不够。这时可以考虑引入“管理器”和“子系统”的概念。游戏玩法管理器创建一个单例模式的BP_GameplayManager通过GameInstance生成并持有负责处理一些全局性的、不属于任何特定角色的游戏逻辑如任务系统、天气循环、全局事件广播。它可以方便地被任何蓝图访问。数据资产不要将武器伤害、角色属性等数值硬编码在蓝图里。使用Data Table或Curve资产来存储。在蓝图中读取这些资产这样策划调整数值时无需重新编译蓝图。组件化将通用功能封装成蓝图组件。例如制作一个“Health Component”组件包含血量、最大血量、受伤、治疗等逻辑。然后把这个组件添加到Character、Vehicle甚至Building蓝图中。这比在每个蓝图里重复编写血量逻辑要高效且一致得多。使用子关卡流送对于大型开放世界将不同区域制作成子关卡通过关卡流送动态加载。这要求你的蓝图协作不能依赖于在编辑器中直接拖放的引用而要更多地使用“按标签或名称获取Actor”或事件分发器来通信。最后保持蓝图整洁的秘诀是单一职责。经常问自己这块逻辑放在这里是不是这个“角色”该干的事如果不是就把它移到更合适的地方。清晰的职责划分会让你的蓝图网络像一篇优美的文章而不是一团乱麻。
1. 项目概述如果你用UE4蓝图做过项目尤其是稍微复杂点的肯定遇到过这种场景角色血量管理、UI更新、敌人AI、场景交互的代码全挤在一个角色蓝图里改个攻击力都得小心翼翼生怕牵一发而动全身。或者你和队友同时修改一个蓝图合并冲突时恨不得把电脑砸了。这背后的根源往往不是蓝图语法不熟而是对UE4 GamePlay框架里那几个核心“角色”——GameMode、PlayerController、Pawn、Character、GameState、PlayerState——到底该干什么、怎么互相“说话”没整明白。理解每个角色的职责边界和它们之间的协作方式是让你的游戏从“能跑起来”到“健壮、可扩展、易于协作开发”的关键一步。这篇文章我们就抛开枯燥的概念罗列直接从一个具体的多人协作射击游戏原型案例出发拆解这些核心角色如何各司其职并通过蓝图节点清晰地“握手”协作。我会分享在实际项目中踩过的坑比如为什么不该在Character里直接处理得分逻辑以及如何利用事件分发器Event Dispatcher和接口Interface实现低耦合的通信让你们的项目蓝图结构清晰得像教科书。2. GamePlay框架核心角色职责深度解析2.1 导演与规则制定者GameMode与GameState你可以把GameMode理解为剧组的导演兼编剧它只在服务器端存在决定了这场“戏”的基本规则和流程。它的核心职责是生成其他角色比如默认的Pawn和PlayerController类管理游戏状态如等待玩家、进行中、结束并定义游戏规则如获胜条件、回合制逻辑。一个常见的误区是把随时间变化的数据比如剩余时间、团队总分放在GameMode里。GameMode是规则的制定者不是数据的记录员。这些需要同步给所有客户端的数据应该交给GameState。GameState就像是剧组里的场记板负责记录和广播当前这场“戏”的全局状态。它在服务器和所有客户端上都存在服务器是权威版本客户端是复制过来的副本。所有玩家都需要知道的全局信息比如游戏已进行时间、当前比分、存活玩家列表都应该放在GameState里。这样做的好处是任何客户端都可以直接从GameState获取这些信息无需向服务器频繁请求。实操心得在蓝图里GameMode的设置是在项目设置里的“Maps Modes”中指定。而GameState的属性如果你希望客户端能实时看到变化务必勾选“Replication”复制。例如定义一个“TeamAScore”整数变量勾选“Replicated”那么当服务器修改它时所有客户端的UI都能自动更新。2.2 玩家的化身与大脑Pawn、Character与PlayerController这是最容易混淆的一组概念。Pawn是玩家或AI在游戏世界中的物理化身可以理解为演员的“身体”。它拥有位置、旋转可以被控制。Character是Pawn的一个子类UE4贴心地为它内置了一个胶囊体碰撞组件和一套基于角色的移动组件Character Movement Component所以对于需要行走、跑跳、游泳等标准人类移动的游戏角色直接使用Character是最方便的。那么谁来控制这个“身体”呢就是PlayerController。它是玩家的“大脑”负责处理玩家的输入鼠标点击、键盘按键并将这些输入转化为对Pawn的控制命令。一个PlayerController通常只控制一个Pawn。它也是处理玩家专属逻辑的好地方比如管理玩家的输入模式UI模式还是游戏模式、处理相机切换、以及持有PlayerState。重要边界Character蓝图里应该主要包含与这个“身体”直接相关的逻辑移动、动画状态机、受击反应、装备附着点。而像“按下E键与门交互”这种输入检测逻辑应该放在PlayerController里由它判断按下E键后再通过接口调用门上的交互函数。这样当你需要更换角色模型换一个Pawn时交互逻辑不需要重写。2.3 玩家的私人档案PlayerStatePlayerState是伴随玩家整个游戏会话的“私人档案”同样存在于服务器和客户端。它用于存储玩家个体的状态数据比如玩家名称、个人得分、杀敌/死亡数、装备情况等。它与PlayerController的生命周期不同——PlayerController在玩家退出游戏时就被销毁了而PlayerState在玩家离开后可能还会短暂存在例如在积分榜上显示直到被清理。为什么个人得分不放在Character里因为Character会死亡、会重生。如果得分存在Character上角色一死得分就清零了这显然不合理。PlayerState才是存储这类持久性个人数据的正确位置。注意事项PlayerState的复制也是默认开启的但要注意性能。不要每一帧都去修改PlayerState里的变量并复制这会产生大量网络流量。通常是在事件发生时如得分、拾取物品才去更新。3. 基于实例的蓝图协作流程拆解我们以一个简单的“团队夺旗”游戏原型为例拆解上述角色如何协作。游戏规则两张地图中央有一面旗子。玩家分为红蓝两队需要夺取敌方旗子并带回己方基地得分。3.1 游戏初始化与角色生成流程GameMode 设置在项目设置中我们指定了自定义的BP_TeamDeathMatchGameMode。在其Event BeginPlay事件中我们设置游戏初始状态如GameState中的RemainingTime300秒并调用SpawnDefaultPawnFor函数为每个连接的玩家生成默认角色BP_TeamCharacter。PlayerController 的接管当玩家客户端加入时服务器会为其创建一个BP_TeamPlayerController实例。GameMode通过PostLogin事件通知有新玩家加入并可以将这个PlayerController与生成的Pawn进行绑定Possess。Character 与 PlayerState 的关联生成的BP_TeamCharacter在BeginPlay时需要知道自己的队伍颜色。它可以通过Get Player State节点获取到属于自己的BP_TeamPlayerState然后从中读取TeamColor变量并据此设置自身材质如红色或蓝色。这个过程通常在服务器端完成然后Character的外观复制到客户端。关键蓝图节点Get Game Mode在任何蓝图中获取当前游戏的GameMode实例。Get Player Controller在Character或HUD蓝图中获取控制它的玩家控制器。Get Player State在Character或PlayerController中获取关联的PlayerState。Cast To类型转换节点至关重要。当你通过上述节点获取到一个通用对象后需要将其转换为你自定义的蓝图类如Cast to BP_TeamPlayerState才能访问其中自定义的变量和函数。3.2 游戏进行中的跨角色通信核心场景红队玩家A夺取了蓝队旗子。事件触发CharacterBP_TeamCharacter与旗子一个Actor发生重叠事件。在旗子的蓝图里检测到重叠的Actor是Character并且通过接口调用确认该Character属于红队。状态变更与通知GameState旗子Actor不应该直接修改分数。它应该触发一个自定义事件比如OnFlagPickedUp并将夺取者的PlayerState作为参数。这个事件的逻辑应该在GameMode或一个专门的管理器比如BP_GameplayManager中监听。这里我们选择在GameMode中处理GameMode监听到事件后首先修改GameState中的全局状态变量例如bBlueFlagTaken true。然后它需要广播这个事件给所有相关方。事件分发Event Dispatcher为了解耦我们在GameState上创建一个Event Dispatcher命名为OnTeamScoreChanged。当GameMode修改了分数后它调用GameState上的一个函数UpdateTeamScore(RedTeam)在这个函数内部除了更新RedTeamScore变量还会Call那个OnTeamScoreChanged事件分发器。多方响应UI更新所有玩家的HUD蓝图或Widget组件在游戏开始时就Bind绑定了GameState的OnTeamScoreChanged事件。当事件被调用时UI自动更新比分显示。音效与提示PlayerController也可以绑定这个事件当自己队伍得分时在客户端本地播放一个欢呼音效和屏幕提示。旗子状态重置GameMode在处理得分后还会调用一个函数来重置旗子的位置和状态。这个流程的优势Character只负责触发“夺旗”这个动作GameMode负责裁决和更新核心规则数据GameState负责存储和广播状态变化UI和其他系统只负责监听和反应。任何一环需要修改比如改变计分规则或UI样式都不会影响其他环节。3.3 使用接口实现灵活交互在上面的例子中旗子需要判断重叠的Actor是否属于某个队伍。我们不应该让旗子蓝图直接去Cast To BP_TeamCharacter因为未来可能有其他类型的Pawn也能夺旗比如车辆。更好的做法是使用接口。创建接口创建一个名为Teamable的蓝图接口里面添加一个函数GetTeamColor返回一个枚举值红队、蓝队。实现接口让BP_TeamCharacter和任何可能需要区分队伍的蓝图都实现这个接口。在BP_TeamCharacter的GetTeamColor函数实现里返回从自身PlayerState中读取的队伍颜色。调用接口在旗子的重叠事件中不再进行类型转换而是使用Does implement interface?节点检查重叠的Actor是否实现了Teamable接口。如果是则调用接口函数GetTeamColor来获取队伍信息。这样做旗子完全不需要知道是谁在跟它交互它只认“接口”。未来增加新的可夺旗单位只需要让新单位实现Teamable接口即可旗子蓝图一行代码都不用改。4. 蓝图协作中的常见陷阱与最佳实践4.1 网络复制Replication的坑网络游戏是蓝图协作的试金石。最常见的坑就是忘了设置复制或者复制了不该复制的东西。该复制没复制GameState里的比分、PlayerState里的个人数据、Character的外观状态如是否持旗这些需要所有客户端看到一致状态的变量必须勾选“Replicated”。忘记勾选的结果就是只有服务器能看到变化其他玩家眼里游戏状态是错的。不该复制的乱复制每一帧都在变化的变量如角色的精确位置和旋转由UE4的移动组件自动处理或者只在本地客户端需要的变量如某个特效的播放状态如果手动复制会增加不必要的网络负担。计算密集的函数也不要在客户端调用Run on Server节点过于频繁。复制回调函数当一个复制变量值发生变化时你可以在其后的“Replication”下拉框中选择“RepNotify”。这会生成一个OnRep_[变量名]事件。这个事件在客户端变量更新时触发但在服务器端不触发。常用来在客户端更新UI或播放效果。例如在PlayerState中设置Kills变量为“RepNotify”当Kills增加时在客户端的OnRep_Kills函数里更新屏幕上的击杀数文本。4.2 引用管理与空指针防护蓝图之间通过引用进行通信。获取引用失败返回null是运行时错误的常见原因。安全的引用获取流程使用Get Game State、Get Player Controller等节点获取对象引用。立即用一个Is Valid节点检查引用是否有效。如果有效再进行Cast To转换。转换后可以再用一个Is Valid检查转换后的对象虽然通常不需要但更保险。典型场景在Character的BeginPlay事件中获取PlayerState。如果这个Character是由AI控制的没有PlayerState那么Get Player State会返回空。你的后续逻辑如设置队伍颜色就必须放在Is Valid为真的分支里否则游戏会崩溃。4.3 输入处理的层级输入处理应严格遵循层级PlayerController 优先将核心的游戏操作移动、跳跃、射击、交互的输入事件绑定在PlayerController蓝图中。PlayerController是输入的“第一接收者”。Pawn/Character 执行在PlayerController的输入事件里调用其当前控制的Pawn或Character上的函数来执行具体动作。例如PlayerController中的“Jump”输入事件调用Controlled Pawn上的Jump函数。UI输入分离当打开菜单时你需要切换输入模式。UE4提供了Set Input Mode节点在PlayerController中。可以设置为“UI Only”仅UI或“Game and UI”游戏和UI。确保UI控件如按钮的点击不会意外触发游戏角色的动作。实操心得对于多人游戏记住一个黄金法则凡是影响游戏核心规则和状态的决定性逻辑必须在服务器端的权威蓝图中执行。客户端只能发起请求通过Run on Server节点和表现效果。例如扣血计算必须在服务器的Character蓝图里进行然后通过复制将血量同步到客户端。客户端只能播放受击动画和屏幕特效。5. 大型项目中的蓝图架构扩展建议当项目规模变大仅靠GamePlay框架的基础角色可能不够。这时可以考虑引入“管理器”和“子系统”的概念。游戏玩法管理器创建一个单例模式的BP_GameplayManager通过GameInstance生成并持有负责处理一些全局性的、不属于任何特定角色的游戏逻辑如任务系统、天气循环、全局事件广播。它可以方便地被任何蓝图访问。数据资产不要将武器伤害、角色属性等数值硬编码在蓝图里。使用Data Table或Curve资产来存储。在蓝图中读取这些资产这样策划调整数值时无需重新编译蓝图。组件化将通用功能封装成蓝图组件。例如制作一个“Health Component”组件包含血量、最大血量、受伤、治疗等逻辑。然后把这个组件添加到Character、Vehicle甚至Building蓝图中。这比在每个蓝图里重复编写血量逻辑要高效且一致得多。使用子关卡流送对于大型开放世界将不同区域制作成子关卡通过关卡流送动态加载。这要求你的蓝图协作不能依赖于在编辑器中直接拖放的引用而要更多地使用“按标签或名称获取Actor”或事件分发器来通信。最后保持蓝图整洁的秘诀是单一职责。经常问自己这块逻辑放在这里是不是这个“角色”该干的事如果不是就把它移到更合适的地方。清晰的职责划分会让你的蓝图网络像一篇优美的文章而不是一团乱麻。
