我的方法有点内存密集型(从《吃豆人》时代的角度来看)，但你只需要计算一次，它适用于任何关卡设计(包括跳跃)。

一次标记节点

当你第一次加载一个关卡时，将所有怪物巢穴节点标记为0(代表与巢穴的距离)。继续向外标记已连接的节点1，连接到它们的节点2，依此类推，直到所有节点都被标记。(注意:如果巢穴有多个入口，这也是有效的)

我假设您已经有了表示每个节点和到它们的邻居的连接的对象。伪代码可能看起来像这样:

public void fillMap(List<Node> nodes) { // call passing lairNodes
    int i = 0;

    while(nodes.count > 0) {
        // Label with distance from lair
        nodes.labelAll(i++);

        // Find connected unlabelled nodes
        nodes = nodes
            .flatMap(n -> n.neighbours)
            .filter(!n.isDistanceAssigned());
    }
}

眼睛移动到距离标签最小的邻居

一旦所有节点都标记好了，路由眼睛就变得很简单了……只需要选择距离标签最小的相邻节点(注意:如果多个节点的距离相等，那么选择哪个节点并不重要)。伪代码:

public Node moveEyes(final Node current) {
    return current.neighbours.min((n1, n2) -> n1.distance - n2.distance);
}

全标记示例

对于我的《吃豆人》游戏，我创造了一个“最短多条回家路径”算法，它适用于我所提供的任何迷宫(在我的规则集内)。它也适用于隧道。

当关卡被加载时，每个十字路口的所有归途数据都是空的(默认)，一旦幽灵开始探索迷宫，它们每次遇到“新的”十字路口或从不同的路径再次遇到已知的十字路口时，它们的归途路径信息就会不断更新。

Dtb23的建议是在每个角落随机选择一个方向，最终你会发现怪物洞听起来非常低效。

然而，你可以利用它低效的“回家”算法，通过在游戏难度中引入更多变化来让游戏变得更有趣。你可以通过应用上面的方法，比如你的路径点或洪水填充来做到这一点，但这样做是非确定性的。所以在每个角落，你都可以生成一个随机数来决定是走最优路线，还是随机方向。

随着玩家不断推进关卡，你将减少玩家选择随机方向的可能性。这将在关卡速度，幽灵速度，吃药丸暂停等之外为整体难度关卡添加另一个杠杆。你有更多的时间放松，而鬼魂只是无害的眼睛，但随着你的进步，时间会越来越短。

我不太清楚你是如何执行游戏的，但你可以这么做:

Determine the eyes location relative position to the gate. i.e. Is it left above? Right below? Then move the eyes opposite one of the two directions (such as make it move left if it is right of the gate, and below the gate) and check if there are and walls preventing you from doing so. If there are walls preventing you from doing so then make it move opposite the other direction (for example, if the coordinates of the eyes relative to the pin is right north and it was currently moving left but there is a wall in the way make it move south. Remember to keep checking each time to move to keep checking where the eyes are in relative to the gate and check to see when there is no latitudinal coordinate. i.e. it is only above the gate. In the case it is only above the gate move down if there is a wall, move either left or right and keep doing this number 1 - 4 until the eyes are in the den. I've never seen a dead end in Pacman this code will not account for dead ends. Also, I have included a solution to when the eyes would "wobble" between a wall that spans across the origin in my pseudocode.

一些伪代码:

   x = getRelativeOppositeLatitudinalCoord()
   y
   origX = x
    while(eyesNotInPen())
       x = getRelativeOppositeLatitudinalCoordofGate()
       y = getRelativeOppositeLongitudinalCoordofGate()
       if (getRelativeOppositeLatitudinalCoordofGate() == 0 && move(y) == false/*assume zero is neither left or right of the the gate and false means wall is in the way */)
            while (move(y) == false)
                 move(origX)
                 x = getRelativeOppositeLatitudinalCoordofGate()
        else if (move(x) == false) {
            move(y)
    endWhile

最初的《吃豆人》并没有使用寻径或花哨的AI。它只是让玩家觉得游戏比实际更有深度，但实际上它是随机的。正如Ian Millington和John Funge在《ai Intelligence for Games》中所述。

Not sure if it's true or not, but it makes a lot of sense to me. Honestly, I don't see these behaviors that people are talking about. Red/Blinky for ex is not following the player at all times, as they say. Nobody seems to be consistently following the player, on purpose. The chance that they will follow you looks random to me. And it's just very tempting to see behavior in randomness, especially when the chances of getting chased are very high, with 4 enemies and very limited turning options, in a small space. At least in its initial implementation, the game was extremely simple. Check out the book, it's in one of the first chapters.

下面是ammoQ的洪水填充想法的模拟和伪代码。

queue q
enqueue q, ghost_origin
set visited

while q has squares
   p <= dequeue q
   for each square s adjacent to p
      if ( s not in visited ) then
         add s to visited
         s.returndirection <= direction from s to p
         enqueue q, s
      end if
   next
 next

它的思想是宽度优先搜索，所以每次你遇到一个新的相邻正方形s，最好的路径是经过p。我相信是O(N)。