10

我只是在考虑将Erlang用于游戏服务器的可能性。(哦,我不是 Erlang 专家,只是考虑舞台)这意味着使用Actor Model进行游戏模拟。当然,最大的吸引力在于它的并发分布在多个节点上。

我目前的大问题是我应该如何执行多角色交互,如碰撞检测。(这只是一个例子)

尽管任何游戏都需要碰撞检测,但从 Actor 模型的本质来看,它看起来效率不高,甚至没有意义,因为它需要全局同步的状态查询和所有目标 Actor 的更新。如果我使用任何同步,它会覆盖 Erlang 演员模型的所有好处。

当然,如果我正确使用空间分区,一次定位演员可能会更小,但这只是一种优化,而不是主要答案。或者这是这个问题的正确答案?通过减少交互参与者的数量来减少同步范围?

4

2 回答 2

9

将地图拆分成更小的部分,让每个部分成为自己的进程(您甚至可以将其拆分得如此之多,以至于每个图块都是自己的进程)。试图移动的玩家将向图块/子地图发送一条消息,说明它正在前往那里,并且图块会回答是否可以。这避免了冲突,因为瓦片/子地图一次只处理一条消息。多个 sub-maps/tiles 可以同时处理消息,所以它仍然是一个并发程序。

于 2012-04-29T11:53:50.567 回答
7

我有一个基于太空的游戏在 Erlang 中做服务器。诀窍是每个位置/节点/等也是一个演员。它连续运行物理并定期将信息发送给每个游戏实体参与者。

当您开始更抽象地思考演员/实体是什么时,整个事情变得更加清晰。例如,碰撞可以是成熟的演员。这使得客户端更容易——将图形和声音效果与碰撞联系起来。在服务器端,它也能做到——在给定时间内防止两个实体之间发生多次碰撞效应。

于 2012-04-30T12:11:40.970 回答