Logic Toolkit

有一些需求既可以用行为树节点实现也可以用普通节点实现，我会困惑是否应该使用行为树节点，之前我的想法是当父节点是行为树节点，后面所有的子节点都要保持使用行为树节点。
目前发现全部使用行为树节点没有普通节点看起来简洁。随机选择分支的例子使用Decorator，实际概率也并不是预期的20%、30%、50%。所以我觉得行为树节点最佳实践可能是只在必要的地方使用，尽量使用普通节点。

通过加权选择多个元素时不能使用 RandomEvaluate。
您需要获取一次 Random.value 并将其与每个元素的权重进行比较以选择运行的位置。
我们将考虑将 WeightSelector 添加到行为树中，并在未来的更新中将 CompositeComponent 公开。

行为树的最佳实践是首先提出“执行条件和动作”，然后考虑“动作的优先级”。
例如，假设我们有以下 NPC。

执行条件和动作

• 无条件：巡逻
• 发现敌人时：追踪
• 当你接近敌人时：攻击
• 体力低于30%时：恢复
• 体力低于20%时：逃跑

优先事项

• 体力低于30%时：恢复
• 体力低于20%时：逃跑
• 当你接近敌人时：攻击
• 发现敌人时：追踪
• 无条件：巡逻

如果按照这个顺序判断并执行，很可能会成为一个优秀的NPC。

如果你不能将“执行条件和动作”视为一个集合，或者如果“动作优先级”没有一致的解释，你可能需要重新考虑行为树是否合适。

caitsithware wrote: ↑2024/09/05 06:26 我们将考虑将 WeightSelector 添加到行为树中

希望普通节点流程中也可以使用WeightSelector，并且每一个分支参数除了Weight还有一个bool的Condition，每次随机只有当分支的Condition是ture时Weight才会被计算。

这是一个角色行为例子，三种实现方式，图1是尽量不使用行为树节点，图2是尽量使用行为树节点，图3是一种平衡。
我认为图3看起来比图1和图2更好，但是图3不容易直接做到，往往是在完成图1或图2后，再优化调整才能实现图3。

假设框架的设计是行为树流程和普通流程统一，行为树节点可以和其他普通节点直接连线，不需要经过一个节点的转换，是不是实践中可能会更容易去判断如何选择节点，很多节点也可以不用区分行为树流程专用和普通流程专用了？

您是说希望直接将执行节点（例如 ActionNode 或 TaskNode 等）连接到行为树的子节点吗？
因为「将执行结果返回给源节点」这一点是相同的，所以可能确实可以直接连接。
不过，由于还有 Decorators 和 Services 之间的差异，无论如何，之后可能还是需要进行一些替换作业。
我会考虑是否可以对此进行支持。

caitsithware wrote: ↑2024/09/06 06:06 您是说希望直接将执行节点（例如 ActionNode 或 TaskNode 等）连接到行为树的子节点吗？
因为「将执行结果返回给源节点」这一点是相同的，所以可能确实可以直接连接。
不过，由于还有 Decorators 和 Services 之间的差异，无论如何，之后可能还是需要进行一些替换作业。
我会考虑是否可以对此进行支持。

我希望能不使用BehaviorTreeExecute或ExecuteTask转换，行为树节点能直接作为执行节点或普通流程控制节点的父节点或子节点

kvfreedom wrote: ↑2024/09/06 05:14 1.png
2.png
3.png
这是一个角色行为例子，三种实现方式，图1是尽量不使用行为树节点，图2是尽量使用行为树节点，图3是一种平衡。
我认为图3看起来比图1和图2更好，但是图3不容易直接做到，往往是在完成图1或图2后，再优化调整才能实现图3。

我发现这种实现方式是更好的

组装节点的最佳方式取决于具体的规格，因此我们无法为您提供这种组装方式是否良好的单独答案。
（另外，我们不提供按照详细规范实施的支持。）
您必须通过反复试验来亲自尝试如何组装它，如果您对如何使用它有任何疑问，请随时询问，我们会回答。