假设你已经有了追逐吃豆人所需的逻辑，为什么不重用它呢?只要改变目标。这似乎比尝试使用完全相同的逻辑创建一个全新的例程要少得多。

如果每个正方形都有一个到中心的距离值呢?这样，对于每个给定的正方形，你可以在所有可能的方向上得到相邻正方形的值。你选择最小值的正方形，然后移动到那个正方形。

数值将使用任何可用的算法预先计算出来。

任何简单、可维护、可靠、性能足够好的解决方案都是好的解决方案。听起来你已经找到了一个很好的解决办法。

寻径解决方案可能比当前解决方案更复杂，因此更可能需要调试。它可能也会变慢。

在我看来，如果它没坏，就不要修。

EDIT

在我看来，如果迷宫是固定的，那么你当前的解决方案就是好的/优雅的代码。不要错误地把“好”或“优雅”等同于“聪明”。简单的代码也可以是“好的”和“优雅的”。

如果你有可配置的迷宫级别，那么也许你应该在最初配置迷宫时进行寻路。最简单的方法就是让迷宫设计师亲自动手。如果你有无数个迷宫，我才会费心自动化这个……或者用户可以自行设计。

(另外:如果路线是手工配置的，那么迷宫设计师可以通过使用次优路线来让关卡变得更有趣……)

对于更传统的寻路算法的替代方案，您可以看看(名称很合适!)吃豆人气味反对象模式。

你可以在启动时在迷宫中弥漫怪物洞的气味，然后让眼睛跟着它回家。

气味设置好后，运行成本非常低。

编辑:很遗憾维基百科上的文章已经被删除了，所以WayBack Machine来拯救…

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

一次标记节点

当你第一次加载一个关卡时，将所有怪物巢穴节点标记为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);
}

全标记示例

实际上，我想说你的方法是一个非常棒的解决方案，与任何类型的寻径相比，运行时间成本几乎为零。

如果你需要将其推广到任意地图，你可以使用任何寻径算法——例如，宽度优先搜索很容易实现——并在游戏运行前使用该算法计算在每个角落编码的方向。

编辑(2010年8月11日):我刚刚看到了关于吃豆人系统的一个非常详细的页面:the Pac-Man Dossier，既然我已经得到了公认的答案，我觉得我应该更新它。这篇文章似乎没有明确地涉及回到怪物房子的行为，但它指出了《吃豆人》中的直接寻路是以下情况:

继续向下一个路口移动(尽管这本质上是一种特殊情况，即“当有选择时，选择不涉及反转方向的方向，如下一步所示); 在十字路口，看看相邻的出口方块，除了你刚刚出来的那个; 选一个离目标最近的。如果有多个方向同样接近目标，则按以下顺序选择第一个有效方向:上、左、下、右。