3 ms·
I'm confused by this article. The author says he's in erlang (which, btw, is not pure functional). And then goes on to describe a system which sounds like an
by dnautics 6y ago
I'm confused by this article. The author says he's in erlang (which, btw, is not pure functional). And then goes on to describe a system which sounds like an object oriented system. But a game programmer would probably actually implement it not as object per se, but maybe backed by an entity component system. But it seems like BEAM languages would be actually quite good at expressing entity systems, which, correct me if I'm wrong, are similar to say checking out and manipulating data in a database.
- ramchip 6y agoI 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.