Is a Component Entity System implemented in Erlang even possible?

Question

I've learned a lot about Erlang the last couple of days and am familiar with component entity systems.

With the process centric approach of Erlang I would suggest that each entity would be an Erlang process instance. As for the CES (Component Entity System) approach I would have a process for like a "MovementSystem" for entities that own a MovementComponent (for example). I would then with tail-recursion "iterate" over all registered entities and send them messages to let them update their own process state rather than doing that as batch-processing by the MovementSystem itself... (what I then wouldn't call an entity system anymore, because in my understanding a CES has all information of all entity and components it is processing, which would mean "shared memory", which is by concept not part of Erlang)

Are those two approaches/paradigms - Erlang and "Component Entity System" - excluding each other, or am I missing something?

(I wouldn't even call this prototype on GitHub (https://gist.github.com/sntran/2986790) a real Component Entity System. This approach there looks more that the Entity-System, it rather looks to me as an gen_event based MQ-approach, for which I would probably use RabbitMQ instead... but that's not relevant here...)

Right now I don't see how these two concepts are even possible to get combined...

Answer 1

Okay, I did further research...

-> https://stackoverflow.com/a/1637134/3850640 This answer to another question to erlang explained it pretty well to me

One thing Erlang isn't really good at: processing big blocks of data.

Where a CES by nature handles a lot of data at once...

So, my answer would be "Yes, it is possible, but not a pretty good choice"...

Answer 2

I do not know about CES, but I do think that you are missing some things.

each entity would be an Erlang process instance ... let them update their own process state rather than doing that as batch-processing by the MovementSystem itself ... which would mean "shared memory", which is by concept not part of Erlang

It sounds as if you want to hold all your state in one place. The simplest way to do this is to use one process and have that process keep its own state. However, there are other ways: you could have a "global state" process that everyone can talk to. You can think of ETS as an example of this. Putting the shared state in a separate process makes synchronization much easier.

If you want to do parallel processing, there are many ways to arrange your code: you could have MovementSystem gen_server:cast to all MovementComponents and have them handle things. This probably works best if the different components of an entity interact and you need to know if something is trying to move and talk at the same time. If components are more independent, you might want to just spawn one-off jobs to handle the movement. Finally, it might be the case that running all movement code in serial is cheap and you just want one process per system.