0

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...

CodeSmile
  • 64,284
  • 20
  • 132
  • 217
Ronald Duck
  • 323
  • 1
  • 11

2 Answers2

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"...

Community
  • 1
  • 1
Ronald Duck
  • 323
  • 1
  • 11
0

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.

Nathaniel Waisbrot
  • 23,261
  • 7
  • 71
  • 99
  • I see, it all turns down to the question "processing all individual states within one dedicated process or to spread the work load to each process handling its own state (where each process represents one entity)... But as far as I've read erlang documentation it seems that erlang isn't that good in "batch processing" many data at once, isn't it? (Right now I'm thinking of outsourcing the intensive work to a dedicated Java-process and synchronising those two via jinterface...) – Ronald Duck Jan 15 '15 at 15:44
  • Again it depends on the specifics. If every CPU cycle counts, I would consider a non-garbage-collected language. Erlang is probably at its best on tasks similar to its roots as a telephony device: tons of concurrent processes handling IO with very low-latency. – Nathaniel Waisbrot Jan 15 '15 at 19:18
  • I'd also caution that *most* of the time when people start thinking about which language to use for a specific task, it's premature optimization. Use the language that's easiest for writing you code, or the language that you want to learn. Down the road (very far down) you may reach a point where switching languages is helpful, but you'll never get there if you hobble yourself trying to pick the "best" language out of the gate. – Nathaniel Waisbrot Jan 15 '15 at 19:21
  • Thanks for that advice. For this task it's kinda requirement driven -> scalability... and therefore I'm taking thoughts on where to subtend the functionalities of the whole architecture. But yes, as you said, erlang is more designed for "[...] tons of concurrent processes [...]". I think it's power will be the backend management. – Ronald Duck Jan 15 '15 at 21:56