在制作一款大型地图RTS游戏时，我的团队遇到了一些寻径方面的性能问题。
A*显然是低效的，不仅因为寻路困难，而且处理大量单位同时移动的成本。
经过研究，显而易见的解决方案是使用FlowField寻路，这是RTS游戏的行业标准。
在创建基本算法后，我们现在遇到的问题是，地图非常大，需要大约766 x 485的网格。当计算要跟随的单元的流场时，这会产生明显的处理冻结或延迟。
有没有人经历过这种情况，或者有任何关于如何使流场更有效的解决方案?我尝试了以下操作:
- 在创建列表时添加流场并稍后引用(一旦创建就可以工作，但显然在创建时滞后)
- 在游戏开始前处理流场并引用列表(由于细胞的绝对数量，这根本不起作用)
- 根据最远的选定单位和目的地之间的距离创建网格(适用于短距离，如果从地图的一端移动到另一端则不适用)。
我想也许把地图分成多个流场，但我正在努力找出如何让它们从一个场移动到另一个场。
有什么建议吗?
提前感谢!
也许这个回答有点晚了。既然你提到这是一款大型RTS游戏，那么计算就不应该局限于一个CPU核心。这里有一些建议可以让你更有效地使用流场。
-
使用多线程为每个单元移动命令计算新的流场
-
分组单元，以便同一命令组中的所有单元共享相同的流场
-
划分流场网格，所以你只需要更新任何在路径(新建筑/移动单位)修改的分区
-
预焙流场网格槽成本:你预焙网格的基本成本(基于环境或其他在游戏期间不会改变的静态值)。
-
划分，例如你有一个766 × 485的地图，设置为800 * 500，划分成100 * 80 * 50的分区，如建议3所述。
你有一个10 * 10 = 100个槽的网格，创建一个有向的图(https://en.wikipedia.org/wiki/Graph_theory)使用一个初始流场地图(不考虑任何游戏单位)，并使用a *算法搜索流场网格在游戏开始前，让你知道分区之间的所有连接。
对于每个新的流场，只在图中用简单的a *搜索标记分区构建流场。然后，如果A*给出的路径中的一个节点完全无法到达下一个节点，则使用替代路由(在图中将该节点标记为阻塞并再次执行A*)。)
6。缓存，保存步骤的流场结果。5供进一步使用(同样的单位从家里刷出并前往敌人基地)。相同的分区路由。如果路径有任何变化，则使缓存无效，并且仅首先使已更改分区的缓存无效，检查该分区是否仍然连接到其他端，然后仅在分区内进行少量更改
-
运行时延迟更新单元命令。如果地图足够大的话。在不使用流场的情况下，立即将单元移动到下一个分区(首先使用A*搜索10*10图以获得下一个分区)。在移动的这段时间，在背景中，使用前面的步骤1-6构建流场。(事实上，如果优化得当，你只需要几毫秒的时间来进行计算，那么单位就会相应地改变它们的路线。大多数情况下，这并没有什么区别，玩家也不会注意到。在最坏的情况下，我们最终不得不搜索所有分区以获得唯一可能的路径，这只是第一次有任何延迟，缓存将最小化时间，因为这是唯一的方法，缓存将被重复使用)
-
每隔几秒(在后台)为每个命令组重新执行上面的构建过程，以防中途发生任何变化。
我可以用更大的随机地图(2000*2000)来实现这一点，并且完全没有fps下降。
希望这对将来的任何人都有帮助。