4 ms·

Thanks very much for the reply. Here's more of a clarifying example: The idea I was going with Animateable was not animation (poor wording on my part), but eff

Thanks very much for the reply. Here's more of a clarifying example: The idea I was going with Animateable was not animation (poor wording on my part), but effictively giving the properties of a creature to a thing, ie magically animating it. So I have an ability in-game that lets me turn anything into a creature, thus merging the Creature interface with whatever other interface this has. From what I'm getting from you, that means every single thing in the game must implement the Animateable interface. Now lets do another one, I want a Metalic property. Say these are things that when hit by lightning will give off lightning damage. Then there's a curse called Midas that will let me turn anything metallic. So I have a Wooden Hammer object which I midas curse mixing in metalic, then a wizard animates it so that it has the properties of a creature, and I have a creature that when I hit with lightning gives off sparks that I can also use to hammer nails. Point being, in this world you're basically requiring every single thing to implement every single interface which sounds like a nightmare, where with more of an ECS style system, you just merge in the new behavior and call it a day.

dilap 5y ago
So caveat, I've never actually used an ECS system, but I've read about the pattern, and I would say it definitely seems better suited to the kind of situation you're describing than interfaces (or inheritence). (I would say interfaces/inheritence are useful for simple high level abstraction of basic concepts with multiple implementations (here's an interface for a compression algorithm, or a RNG, or whatever), not so useful for trying to model complex game-world relationships. And to me, the useful part is the interface, whereas inheritence mixes in two unrelated concepts: implemementation-sharing and interface.) But you don't need either of those for ECS, right? If I understand it correctly, ECS at its core is basically an optimization of the struct-of-arrays datastructure. E.g., something like this is a super-basic ECS: struct World { Comp1[] Comp1 bool[] HasComp1 Comp2[] Comp2 bool[] HasComp2 ... int NumEntities // all arrays have this length } I'm a big fan in general of struct-of-arrays vs collection-disparate-structs-with-pointers. Besides being way faster, it tends to make code clearer, too. ECS seems like a more efficient and convenient evolution of that pattern. At least from what I've read. No real experience. Take with 13 grains of salt. :-) P.S. If you feel like it, I'd be happy to explore some concrete code (you first!). It's always very interesting to me to try to explore all possible ways to express some concept in code.

dilap 5y ago

So caveat, I've never actually used an ECS system, but I've read about the pattern, and I would say it definitely seems better suited to the kind of situation you're describing than interfaces (or inheritence). (I would say interfaces/inheritence are useful for simple high level abstraction of basic concepts with multiple implementations (here's an interface for a compression algorithm, or a RNG, or whatever), not so useful for trying to model complex game-world relationships. And to me, the useful part is the interface, whereas inheritence mixes in two unrelated concepts: implemementation-sharing and interface.) But you don't need either of those for ECS, right? If I understand it correctly, ECS at its core is basically an optimization of the struct-of-arrays datastructure. E.g., something like this is a super-basic ECS: struct World { Comp1[] Comp1 bool[] HasComp1 Comp2[] Comp2 bool[] HasComp2 ... int NumEntities // all arrays have this length } I'm a big fan in general of struct-of-arrays vs collection-disparate-structs-with-pointers. Besides being way faster, it tends to make code clearer, too. ECS seems like a more efficient and convenient evolution of that pattern. At least from what I've read. No real experience. Take with 13 grains of salt. :-) P.S. If you feel like it, I'd be happy to explore some concrete code (you first!). It's always very interesting to me to try to explore all possible ways to express some concept in code.