我只是想为游戏服务器提供 Erlang 的可能性。 （哦，我不是Erlang专家，只考虑阶段）这意味着使用 Actor Model 进行游戏模拟。当然，最吸引人的是它在多个节点上的并发性。
我目前的一个大问题是如何执行碰撞检测等多角色互动。 （这只是一个例子）
虽然在任何游戏中基本上都需要碰撞检测，但是在Actor模型的本质中，它看起来效率不高甚至没有意义，因为它需要全局同步状态查询并更新所有目标actor。如果我使用任何同步，它将覆盖Erlang的actor模型的所有好处。
当然，如果我正确使用空间分区，那么一次定位演员可能会更小，但这只是一个优化，而不是一个主要的答案。或者这是这个问题的正确答案吗？通过减少交互参与者的数量来减少同步范围？
答案 0 :(得分：9)
将地图拆分成较小的部分，让每个部分都是自己的过程（你甚至可以将它拆分得太多，以至于每个图块都是它自己的过程）。试图移动的玩家将向平铺/子地图发送一条消息，说明它正在那里，并且如果没有问题，则平铺应答。这避免了冲突，因为一次只有一个消息由tile / sub-map处理。多个子映射/磁贴可以同时处理消息，因此它仍然是并发程序。
答案 1 :(得分：7)
我在Erlang中有一个基于太空的游戏服务器。诀窍是每个位置/节点/等也是一个演员。它持续运行物理，并定期将信息发送给每个游戏实体。
当你开始更抽象地思考一个演员/实体是什么时，整个事情变得更加清晰。例如，碰撞可以是完全成熟的演员。这使得客户端更容易 - 将图形和声音效果与碰撞联系起来。在服务器端，它也可以 - 在给定时间内多次防止两个实体之间的多次碰撞效应。