GenericAISystem 最佳实践

GenericAISystem 最佳实践

总结 GenericAISystem 在项目接入、配置维护、扩展分层和调试验证中的推荐做法。

先分层接入

最小命令单位、小队、阵型、Movement Intent、Tactical Assignment、StateTree 深度集成应逐层接入。每一层都有明确验证点，不要在第一轮同时配置所有 Source、Filter、Allocator 和自定义命令。

推荐顺序是先跑通玩家或脚本直接下发的具体命令，再接 StateTreeStack 的层级覆盖和回退；需要复杂执行时再引入 Queue；最后再让 Tactical Assignment 自动选择候选单位和目标。这样每一步都有清楚的失败边界。

不要把所有 AI 塞进一颗 StateTree

长期项目里，最容易失控的是把基础 AI、小队覆盖、顶层命令、连招执行、战术分配和目标过滤全部塞进同一颗 StateTree。更稳的拆法是：Stack 管控制权，Queue 管执行序列，Tactical Assignment 管 AI 自动分配命令，CommandSystem 管具体命令生命周期。

参数集中维护

把命令片段、小队角色、阵型槽位、Tactical Assignment Batch 和 StateTree Key 当作配置资产维护。核心功能文档不重复解释参数，参数变更统一回到 参数参考。

扩展点放在边界上

• 命令语义扩展放在 UGAIS_CommandDefinition。
• Tactical Assignment 的意图到命令映射放在 UGAIS_UnitComponent.CommandIntentMappings 或 Unit/Actor/组件侧自定义 IGAIS_CommandIntentResolver。
• 行为层覆盖放在 StateTreeStack，复杂执行序列放在 StateTreeQueue。
• 小队资格和角色规则放在 UGAIS_SquadDefinition。
• 移动系统接入放在 UGAIS_UnitMovementIntentDriver。
• 队伍系统接入放在 UGAIS_ProjectPolicy。

保留项目真源

GAIS 不应该抢走项目已有的 Movement、GAS、Team 或 Animation 真源。用 Driver、Policy、Interface 和 CommandDefinition 做胶水。

把网络所有权和玩法授权分开

Command、Squad、Formation、Team 和 Movement Intent 的可变状态由服务端维护。GAIS 提供的 Server... RPC 是 owning client 的请求通道，不是玩法权限判定。项目仍要在服务端检查玩家是否能控制该单位/小队、是否能换阵、改角色或下发该命令。非 owning Actor 的请求统一经 PlayerController 或项目网络服务转发。

调试优先看摘要

先看 GameplayDebugger 的 Blackboard、Stack、Queue、CommandSystem、Formation、Squad、Team 摘要，再深入参数。slot-score 诊断只在非 Shipping/Test 构建可用。