塔防游戏中的多线程寻路

Question

我正在制作一个塔防御游戏，我被困在了寻路的多线程中。如果我没有使寻路成为一个NSInvocationOperation，那么在渲染中会有越来越多的暂停，我有更多的恶魔和塔。

然而，我不能解决“锁定”问题。我经常在枚举我的fiend时遇到崩溃。如果我在寻路时尝试锁定主线程中的枚举，游戏仍然锁定，并且我失去了多线程的全部要点。

如何解决这类问题？

Answer 1

线程化无疑会对延迟策略有所帮助，比如在路径查找完成之前就开始在总体方向上移动。

编辑:我没注意到你说是你的fiend数组导致了问题。我认为您最好的选择是松散耦合。尽量不要让路径查找器依赖于你的fiend数组。给它发送一份它需要的数据的拷贝(首发位置，目标位置，等等)并取回一组点数。不要给它访问整个数组的权限，甚至不要给它一个对任何魔兽对象的引用。

Answer 2

想一想，当另一座塔被放置时会发生什么。敌人要么在他们的路径决定中考虑新塔，要么不考虑。确定这些新路径需要时间，而且无论您选择哪种多线程解决方案，这些新路径都会导致延迟。问题最终出在你的寻路算法上。如果计算时间太长，那么你会看到延迟。

看看你可以避免找到那些路径的方法。在(x，y)位置掉下一座塔对所有敌人都有影响吗？你能只计算出几条路径，然后敌人选择走哪一条吗？您是否可以缓存路径并重用已计算的部分(如河流如何与分支支流一起流动)？

我认为有很多方法可以减少路径查找在您的问题中的影响。

Answer 3

我同意Tim Rupe的观点，优化寻路可能会有所帮助。

另一种(附加)方法是将“当前”路径数组与“下一个”路径数组分开。因此，游戏继续当前的路径数组，而下一个数组在另一个线程中计算。这避免了死锁、崩溃等。

然后，在某个明确定义的点上，将“next”替换为“current”(由互斥锁或其他东西保护)。基本上，您总是在处理快照-但您可以控制快照的交换速率(前提是您的寻径算法不是太慢)。