塔防游戏中A *实现的性能降低

9

我正在Flash中制作没有预定义路径的塔防游戏。

尽管我的网格是40x40（小？），但每次重新计算时A *都在挣扎。因此，我进行了自己的修改以简化重新计算，并且触摸的单元数减少到900（在根附近进行修改时）。放置新塔时，它仍会冻结很短但可检测的时间。

这是一个实现问题，还是40x40太多了？

编辑：

我的代码的结构：

所有数据都保存在二维单元格数组中。
每个单元在路径方向（顺时针为1-8）中包含其父级，并在路径中包含其子项的按位编码的数组（每个位代表一个子项）。
搜索是由A *执行，并估计了欧几里得距离。

— 丹妮
source

您将需要在这里更加具体。我们不知道您的代码是什么样，它的结构如何等等，因此我们无法就导致它变慢的原因得出任何结论。

— 肖恩·詹姆斯

1

当我最后一次实现A *时，我记得它在64x64网格中的运行时间最多为 1ms。是的，这似乎与您的实现有关。我建议发布您的代码或其要点，以便我们进一步为您提供帮助。

— 马克·穆勒

看到我添加的编辑

— Dani

1

如果40x40太慢，则很有可能您做错了什么。发布您的代码或对其进行配置。或者，将其放大并查看会发生什么-如果80x80网格花费的时间是原来的四倍以上，那么您的内容就会被破坏。

— ZorbaTHut 2010年

标题可以提供更多信息吗？

— tenpn

4

我无法发表评论，但在Flex的第一篇文章中，其他所有内容都是猜测。

— 乔纳森·菲斯科夫（Jonathan Fischoff）
source

如何在Flex中配置Flash项目？

— Dani

是的，没有。我不认为您直接加载Flash项目。我认为您也许可以在没有源代码的情况下对SWF进行配置，但是仍然可以获得功能级别的信息。我会做一个谷歌搜索“分析Flex中的Flash项目”之类的。我做到了，得到了：flexblog.edchipman.ca/…看起来很有希望。

— 乔纳森·费斯霍夫

谢谢，真的帮助我找到了有问题的部分（不在算法中，请参阅问题注释）

— Dani

13

我假设TD是“塔防”

我认为A *为此会有些落伍。

在游戏开始时，从退出点向游戏区域填充洪水以创建移动地图：

 |---------|
 |5|4|3|3|3|
 |5|4|3|2|2|
->5|4|3|2|1->
 |5|4|3|2|2|
 |5|4|3|3|3|
 |---------|

并且移动总是朝着值较低的正方形移动。

玩家放置塔楼时，更新八个相邻方块中的每个方块：对于每个方块，将其移动值设置为比最低的相邻值大一个。如果值更改，请以更新的正方形为中心重复该过程。然后，要检查通往出口的路线是否畅通，请确保所有正方形都与一个较小值的正方形相邻。

当玩家移走塔楼时，将移动值设置为比最低的相邻方格大一个，然后重复上述过程。

一种更简单的方法是重新填充洪水。

— 斯基兹
source

6

至少在算法上，对于少量单元（大致为电路板的长度），重新填充泛滥比进行A *更为昂贵（而且由于这是Flash，因此像内存布局这样的非算法常量可以做到）才能非常有效地使用）。但是，对于许多通信单位而言，这是一个非常好的模型，称为协作扩散-scalablegamedesign.cs.colorado.edu/wiki/Collaborative_Diffusion。

@Joe Wreschnig：很棒的链接。我以前曾经使用过该技术，但从未知道它叫什么。谢谢。

— tenpn

@Joe，只要地图上至少有一些障碍，我认为这不会比调用A *更有效。也就是说，我相信仅对于几乎没有任何单位的大范围开放，几乎无障碍的地图，情况可能会更糟。

— edA-qa mort-ora-y

@edA：根据定义，洪水填充最终必须接触地图上的每个可访问点；A *为必须接触的点提供了公认的上限，该点最多是地图上每个可访问的点，并且通常更少。泛洪填充是一种用于优化诸如内存布局之类的更简单算法，但是就像我说的那样，在Flash中可能并不重要。

@Joe，我正在争论的是，即使只有少数几个塔，A *也可能会碰到几乎所有空间。但是对于N个怪物，它只需要超过total_squares / N即可比洪水填充效率低。

— edA-qa mort-ora-y

2

奇怪，我以为我回答了，但答复似乎不见了。使您的搜索算法可以分多个步骤进行更新，这样，当您放置塔楼并播放动画时，您可以每帧进行一点操作，并且需要大约半秒钟到第二秒钟的时间来更新您的A *没有明显的停顿。这是延迟-如果您无法加快速度，找到隐藏它的方法。在放置塔的同时播放动画对于游戏来说是很自然的，而imo是隐藏它的好地方。

— j
source

总的来说，这是一个好主意，但对于这个特定的问题是不利的。在这么小的网格上的A *应该几乎是即时的，而不要花费大量时间。

— davr

很公平。这是我能给出的唯一可以解决该问题而又不知道会导致速度降低的实现细节的答案。

— Kaj 2010年

0

首先，您可以将数组更改为向量-应该可以提高速度。发布代码，我们也许可以提出更多优化建议。

— 伊恩
source

0

我想您的速度下降是因为您正在同时计算所有字符的路径。计算一个字符的路径很快，但是如果场景中有两个打字符，则可能会陷入困境。

相反，您应该将负载分散到几帧上。错开AI更新，以便不同的角色在不同的帧上更新其路径。如果角色直到一秒钟后才做出反应，但是仅仅一帧不会引起不良反应，那将是真正值得注意的。

— 跳动
source

大约一年前就回答了这个问题，但仅因Grace的编辑工作而被颠覆。（它与太多字符无关。）

谢谢你让我知道。我没注意到日期。

— jhocking 2011年