0

最近几天我学到了很多关于 Erlang 的知识，并且熟悉组件实体系统。

使用 Erlang 的以流程为中心的方法，我建议每个实体都是一个 Erlang 流程实例。至于 CES（组件实体系统）方法，对于拥有一个 MovementComponent（例如）的实体，我会有一个类似“MovementSystem”的过程。然后，我将使用尾递归“迭代”所有注册实体并向它们发送消息以让它们更新自己的进程状态，而不是由 MovementSystem 本身作为批处理......（我不会称之为不再是实体系统，因为据我了解，CES 拥有它正在处理的所有实体和组件的所有信息，这意味着“共享内存”，这在概念上不是 Erlang 的一部分）

这两种方法/范式 - Erlang 和“组件实体系统” - 是相互排斥的，还是我遗漏了什么？

（我什至不会在 GitHub ( https://gist.github.com/sntran/2986790 ) 上称这个原型为真正的组件实体系统。这种方法看起来更像实体系统，在我看来它更像是一个基于 gen_event 的 MQ 方法，我可能会使用 RabbitMQ 来代替......但这与这里无关......）

现在我看不出这两个概念是如何结合起来的......

4

2 回答 2

1

好吧，我做了进一步的研究......

-> https://stackoverflow.com/a/1637134/3850640 这个对erlang的另一个问题的回答很好地解释了我

Erlang 不擅长的一件事是：处理大块数据。

CES本质上一次处理大量数据的地方......

所以，我的回答是“是的，有可能，但不是一个很好的选择”......

于 2015-01-25T13:57:24.657 回答
0

我不了解 CES，但我确实认为您遗漏了一些东西。

每个实体都是一个 Erlang 进程实例……让他们更新自己的进程状态，而不是由 MovementSystem 本身进行批处理……这意味着“共享内存”，这在概念上不是 Erlang 的一部分

听起来好像您想将所有状态保存在一个地方。最简单的方法是使用一个进程并让该进程保持自己的状态。但是，还有其他方法：您可以拥有一个每个人都可以与之交谈的“全局状态”过程。您可以将ETS视为一个例子。将共享状态放在单独的进程中会使同步变得更加容易。

如果你想做并行处理，有很多方法可以安排你的代码：你可以让gen_server:cast所有的运动组件都有运动系统，让他们处理事情。如果实体的不同组件交互并且您需要知道某物是否试图同时移动和说话，这可能最有效。如果组件更加独立，您可能只想生成一次性作业来处理移动。最后，串行运行所有运动代码可能很便宜，而您只需要每个系统一个进程。

于 2015-01-15T14:35:42.943 回答