在过去的几天里，我学到了很多关于Erlang的知识，并且熟悉组件实体系统。
使用Erlang以流程为中心的方法，我建议每个实体都是一个Erlang流程实例。至于CES（组件实体系统）方法，我将为拥有MovementComponent的实体（例如）提供一个类似于"运动系统"的过程。然后，我会使用尾递归"迭代"所有注册的实体并向他们发送消息，让它们更新自己的进程状态，而不是由 MovementSystem 本身进行批处理......（然后我不会再称之为实体系统了，因为在我的理解中，CES拥有它正在处理的所有实体和组件的所有信息，这意味着"共享内存"，从概念上讲，它不是Erlang的一部分）
这两种方法/范式 - Erlang 和"组件实体系统" - 是相互排斥，还是我错过了什么？
（我什至不会在 GitHub （https://gist.github.com/sntran/2986790） 上称这个原型为真正的组件实体系统。这种方法看起来更像实体系统，在我看来，它是一种基于gen_event的 MQ 方法，为此我可能会使用 RabbitMQ 代替......但这在这里无关紧要...
现在我看不出这两个概念是如何结合在一起的......
好的，我做了进一步的研究...
-> https://stackoverflow.com/a/1637134/3850640对 erlang 的另一个问题的回答向我解释得很好
Erlang 并不擅长的一件事是：处理大块数据。
CES本质上要同时处理大量数据......
所以，我的回答是"是的，这是可能的，但不是一个不错的选择"......
我不知道CES，但我确实认为你错过了一些东西。
每个实体都是一个 Erlang 流程实例 ... 让他们更新自己的进程状态，而不是由 MovementSystem 本身进行批处理 ... 这意味着"共享内存"，从概念上讲，它不是 Erlang 的一部分
听起来好像你想把你所有的州都放在一个地方。执行此操作的最简单方法是使用一个进程，并使该进程保持自己的状态。但是，还有其他方法：您可以拥有一个每个人都可以与之交谈的"全局状态"过程。您可以将 ETS 视为一个例子。将共享状态放在单独的进程中使同步变得更加容易。
如果你想做并行处理，有很多方法可以安排你的代码：你可以让MovementSystem gen_server:cast到所有的MovementComponents，并让它们处理事情。如果实体的不同组件进行交互，并且您需要知道是否有东西试图同时移动和说话，这可能效果最好。如果组件更加独立，您可能只想生成一次性作业来处理移动。最后，可能的情况是，串行运行所有移动代码很便宜，并且每个系统只需要一个进程。