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