大型 RTS 地图上的 FlowField 寻路答案

【问题标题】：FlowField Pathfinding on Large RTS Maps大型 RTS 地图上的 FlowField 寻路
【发布时间】：2022-11-17 03:06:55
【问题描述】：

在构建大型地图 RTS 游戏时，我的团队在寻路方面遇到了一些性能问题。

A* 显然效率低下，这不仅是因为寻找路径的问题，而且是因为大量单元同时移动的处理成本。

经过研究，显而易见的解决方案是使用 FlowField 寻路，这是目前 RTS 游戏的行业标准。

在创建基本算法后，我们现在遇到的问题是地图非常大，需要大约 766 x 485 的网格。这会在计算要遵循的单元的流场时造成明显的处理冻结或滞后。

有没有人以前经历过这种情况或有任何关于如何使流场更有效率的解决方案？我尝试了以下方法：

在创建列表时将流场添加到列表并稍后引用（一旦创建就可以工作，但明显滞后于创建。）
在游戏开始前处理流场并引用列表（由于单元格数量巨大，这根本行不通。）
根据最远的选定单位和目的地点之间的距离创建网格（适用于短距离，如果从地图的一端移动到另一端则无效）。

我正在考虑将地图拆分成多个流场，但我正在尝试弄清楚如何让它们从一个场移动到另一个场。

对此有何建议？

提前致谢！

【问题讨论】：

FlowField 的网格很大。也许您可以将 HPA*（分层寻路 A*）的思想应用于 FlowField 算法。通常，游戏倾向于生成相对较小的（可到达）区域的（静态）图（细化技术用于使路径短而平滑）。这对于开放地图（即没有很多复杂的障碍）特别有用。事实上，这与 HPA* 所做的非常接近。请注意，对于此类问题，您肯定会在 gamedev.stackexchange.com 上获得更多关注。

标签： algorithm performance unity3d game-physics path-finding

【解决方案1】：

也许这是一个迟到的答案。既然你提到这是一款大型 RTS 游戏，那么计算应该不会局限于一个 CPU 核心。有一些建议可以帮助您更有效地使用流场。

使用多线程为每个单元移动命令计算新的流场
分组单元，使同一命令组中的所有单元共享相同的流场
对流场网格进行分区，因此您只需更新路径中有修改的任何分区（新建筑/移动单元）
预烘焙流场网格插槽成本：您预烘焙网格的基本成本（基于环境或其他在游戏过程中不会改变的静态值）。
划分，例如你有 766 x 485 的地图，将其设置为 800 * 500，按照建议 3 中的说明将其分为 100 * 80 * 50 个分区。

你有一个 10 * 10 = 100 个槽的网格，创建一个定向的图形(https://en.wikipedia.org/wiki/Graph_theory) 使用初始流场图（不考虑任何游戏单元），并使用 A* 算法搜索流场网格在游戏开始之前，让您知道分区之间的所有连接。

对于每个新的流场，仅使用由简单的 A* 搜索标记的分区构建流场图形.然后如果 A* 给出的路由的一个节点完全被阻止无法到达下一个节点，则使用替代路由（将节点标记为被阻止并在此再次执行 A*图形)

5.Cache，保存step.4的流场结果以供进一步使用（同一单位从家里生成并前往敌方基地。相同的分区路线。如果路径有任何变化则使缓存无效，并且仅使更改的缓存无效首先分区，检查这个分区是否仍然连接到其他边，然后只在分区内进行微小的更改）
运行时延迟更新单位的命令。如果地图足够大。立即将单元移动到下一个分区，而不使用流场，（先使用 A* 搜索 10*10 图以获得下一个分区）。在此移动期间，在后台使用前面的步骤 1-5 构建流场。（事实上，如果优化得当，您只需要几毫秒即可进行计算，然后单位会相应地更改路线。大多数时候没有区别，玩家也不会注意到任何事情。在最坏的情况下，我们最终有搜索所有 patitions 以获得唯一可能的路径，这只是第一次会有任何延迟，并且缓存将清除它，因为它是唯一的路径并且缓存将被重复使用）
每隔几秒为每个命令组（在后台）重新执行一次上述构建过程，以防万一中间发生任何变化。

我可以使用更大的随机地图 (2000*2000) 来实现这一点，而 fps 根本不会下降。

希望这对将来的任何人都有帮助。

【讨论】：