3 ms·
I think it’s a common trap for Erlang beginners to try to represent all entities (player, monster, room, etc.) as processes sending messages to each other, the
by ramchip 6y ago
I think it’s a common trap for Erlang beginners to try to represent all entities (player, monster, room, etc.) as processes sending messages to each other, the way you’d use classes in OOP. It’s one way to learn the concepts, but in real apps it leads to messy, brittle code. Erlang processes really shine when they’re used as units of fault tolerance, not a code organization tool.
For an entity system ETS could be interesting, but it involves copying data on every read/write which could be a problem in games...
- MauranKilom 6y agoWhat do you use for code organizational purposes then?
- dnautics 6y agoModules. Basically something between a namespace and a shared object (.so)
- dnautics 6y agoSure. You wouldn't use pure erlang for a game where perf is critical, but not every game is like that. I bet you could even write a fantastic AAA game by carefully dropping into NIFs as necessary. I think though my argument is that you also wouldn't use objects for that sort of thing either. The brittleness of the code has nothing to do with the underlying vm, or its performance, or even it's concurrency, and everything to do with the code architecture and data organization, which is isomorphic between genservers and objects.