演员模型和碰撞检测

Question

10

我在考虑将 Erlang 应用于游戏服务器，使用 Actor Model 进行游戏模拟。其中最大的吸引力当然在于它可以分布在多个节点上实现并发。

但目前我遇到了一个问题，就是如何处理多参与者交互，例如碰撞检测（这只是一个例子）。

虽然在任何游戏中都需要碰撞检测，但在 Actor Model 的本质中，它似乎并不高效且甚至没有意义，因为需要对所有目标参与者进行全局同步状态查询和更新。如果使用任何同步方法，都会覆盖 Erlang Actor 模型的所有优势。

当然，如果正确地使用空间划分技术，可以减少同时定位的参与者数量，但这只是一种优化而非根本解决方案。那么这是否是这个问题的正确答案？通过减少交互参与者的数量来缩小同步范围？

- eonil

2个回答

7

我有一个以Erlang作为服务器的基于太空的游戏。这个游戏的技巧是每个位置/节点等都是一个actor。它连续运行物理引擎并定期向每个游戏实体actor发送信息。

当你开始更抽象地思考actor/entity是什么时，整个系统变得更加整洁。例如，碰撞可以成为完全成熟的actor。这使得客户端更容易-将图形和声音效果与碰撞相结合。在服务器端，也有同样的好处-防止在给定时间内两个实体之间发生多次碰撞效果。

- Nialscorva

所有的物理计算都在单个角色中完成吗？你是如何实现物理计算的呢？ - eonil

3

是的，我正在使用Bullet来运行物理效果。实体演员跟踪自己的游戏状态，相互攻击，决定移动等等。它们向位置发送指令，位置运行模拟。位置持续运行并定期向实体发送“你在这里”的信息以及“你与X发生了碰撞”的信息。实体也会向位置发送查询请求。 - Nialscorva

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Emil Vikström · Accepted Answer

将地图分割成较小的部分，并使每个部分成为自己的进程（您甚至可以将其分割到每个瓦片都是自己的进程）。试图移动的玩家将向瓦片/子地图发送消息，告诉它要去哪里，然后瓦片会回答是否可以。这样可以避免碰撞，因为每次只有一个消息被瓦片/子地图处理。多个子地图/瓦片可以同时处理消息，因此仍然是一个并发程序。