在吃豆人中，鬼魂会独立选择路径来寻找吃豆人吗？

Question

所以我最近在我的手机上玩了很多吃豆人，我想知道这些鬼魂似乎是如何独立工作的。我在想它会如何被编程。

我想到的一个选项是线程。所有 4 个幽灵都在各自的线程中运行，并以某种方式找到了 pacman 的位置。但是让四个线程工作似乎有点过分，而且同步会很困难。另外，google 用 Ja​​vascript 编写的 pacman 不支持线程，所以它可以在没有线程的情况下完成，并且必须有一个更简单的方法。

我的第二个想法是事件处理程序。我只是将 pacman 将触发的 'directionChanged' 事件连接到 4 个事件处理程序，每个事件处理程序一个。然后每个幽灵决定走哪条路去吃豆子。我认为这更可能是正在发生的事情。但如果事件处理程序同步执行，它可能会变慢，因为路径必须按顺序计算，并且第 4 个重影需要时间来改变方向，这可能会产生明显的延迟（可能）。此外，当鬼魂撞墙时，它们会自己触发一个事件，并且它们的事件处理程序会改变鬼魂的方向。但是考虑到 pacman 改变方向和四个幽灵响应的频率，事件处理程序似乎也有点太多了。

我是说上面的想法有点过头了，因为记得这个游戏是 30 年前写的，当时 cpu 时间和内存都很稀缺，所以我认为必须有一个更简单的方法。

此外，即使吃豆人静止，鬼魂似乎也在走不同的道路。是否所有的幽灵都使用完全不同或不同优化的寻路算法？

我更感兴趣的是找出所有幽灵似乎如何同时为自己工作，而不是他们使用的寻路算法。想法？

Answer 1

有很多关于 pacman 如何工作的重要信息here，包括一些关于幽灵行为的详细记录。

**注意，我不久前从Pathfinding Algorithm For Pacman 找到了此信息。

编辑：

这个博客post 有更多关于鬼魂的信息。

Answer 2

在渲染每一帧之前，我会遍历幽灵。这种方式没有事件、线程或异步问题。每个鬼魂可能都有一个非常粗略的启发式来计算它的动作和决定它的决定（左转或右转，没有动作，等等）。

Here's an implementation 你可以去看看。 :)

Answer 3

你想得太多了。

按照视频游戏标准，线程和事件处理程序非常慢。多线程游戏引擎是一项相对较新的发明，实际上是在 Pacman 发布几十年后。 Pacman 的微不足道的逻辑将发生在一个相当紧凑的循环中，类似于这个非常简化的伪代码：

while (!pacman_dead) {
  foreach ghost {
    if (ghost has hit a wall) {
      if (pacman to left) turn left
      if (pacman to right) turn right
    } else {
      go straight
      if (ghost touched pacman) {
        pacman_dead = true
      }
    }
  }

  handle_input();
  move_pacman();
  draw_screen();      
}

这是游戏中相当常见的模式，它给人一种并发的感觉。通常，游戏将在单个循环中运行，这会使游戏状态在屏幕重绘之间的空间中增加一些微小的增量。这就是为什么性能在游戏开发中仍然非常重要的原因：您的游戏必须迭代每个需要做某事或做出某些决定的游戏内对象（AI 控制的对手、移动平台、简单的动画、等）并每秒至少更新其状态 30 次。