A simpler ECS pattern in plain C
https://www.gamedev.net/articles/programming/general-and-gam...
See post on C struct composition: https://arpitbhayani.me/blogs/inheritance-c
A Simple Entity Component System (2019)
11–20 of 38 posts
Re: A Simple Entity Component System (2019)
#12IMO, ECS is a better way of doing OO (even on a non-OO language) than OO languages themselves: - Avoid the inheritance vs. composition issue - Entity as a first-class concept (no more Object vs. "Just Value Object", confusion regarding equality of objects, object hash methods) - System as a first-class concept (not just a consequence of a call stack between multiple inter-dependent objects) - It serves much of the sa…
That's a really interesting take. I'd love to see an experimental language based around this approach because I think it could really push your idea much further than a library.
Re: A Simple Entity Component System (2019)
#13That's certainly an interesting way to organize things, though I dislike the reliance on several 'manager/coordinator' classes. (though part of this is my superstition that class names shouldn't end in -er or -or) The main mechanism seems to be for 'systems' being able to iterate over tuples of 'components' of a specific type for all 'entities'. I can't help but wonder if there isn't a more elegant way of doing this…
One of the main goals of ECS is to improve the use of the cache and reduce the amount of dereferencing. An alternative approach, which does not sacrifice the more common OOP style: https://www.doc.ic.ac.uk/%7Escd/ShapesOnwards.pdf
Is that really what you get when you put all entity IDs in a set and iterate over those? Sure the component arrays are packed but that's kind of pointless if you're iterating over them in a random order (note that the system proposed here will also gradually destroy the ordering in the packed arrays).
Not that I know an easy way to keep a lists of components that ensure that iterating over them is anywhere close to cache-efficient. Perhaps some kind of self-ordering system would work? (you could for instance move components to consecutive positions as a system uses them, ideally in way that's stable so you don't mess up the ordering of other systems)
Re: A Simple Entity Component System (2019)
#14Something I don't get about ECS: How do you handle interactions between systems, and especially side effects that can affect multiple systems?
Because of those, the systems can't really be considered truly independent, can they?
Doesn't this cause complexity to go through the roof?
Re: A Simple Entity Component System (2019)
#15IMO, ECS is a better way of doing OO (even on a non-OO language) than OO languages themselves: - Avoid the inheritance vs. composition issue - Entity as a first-class concept (no more Object vs. "Just Value Object", confusion regarding equality of objects, object hash methods) - System as a first-class concept (not just a consequence of a call stack between multiple inter-dependent objects) - It serves much of the sa…
I have a similar feeling, but have not converted that feeling into building production code that way yet, partially because it conflicts with a large amount of existing code that I work on in terms of design. It definitely has tradeoffs, but I found a large class of problems went away when I used it.
Re: A Simple Entity Component System (2019)
#16ECS is a one of the possible designs of what we usually call "the gamestate" that is the dynamic structure that holds the game world simulation. But the origin of ECS is Data Oriented Design, also known as DOD, that emerged as a reaction to the bad properties of OOP. DOD is more general and IMHO more interesting than ECS. I have not yet seen a satisfying implementation of ECS, it can be extremely fast compared to OOP…
I agree - I have looked into a 2 or ECS implementations, and they either seemed awkward, or brought in a bunch of other concerns I did not care about, and in the end decided to roll my own for some games I was building. It was pretty simple in the end. Dependencies definitely became a bit lengthy in some cases, but I didn't hate that, in that it makes the coupling explicit.
Re: A Simple Entity Component System (2019)
#17The horse is thoroughly out of the barn on this one, but "an Entity Component System" is a misnomer similar to referring to "a Model View Controller". Sometimes it's written as "Entity-Component-System" to clarify that "entities", "components", and "systems" are all concepts within the ECS architecture.
Re: A Simple Entity Component System (2019)
#18Bevy[0] (written in Rust) has a fairly mature ECS implementation.
Re: A Simple Entity Component System (2019)
#19Something I don't get about ECS: How do you handle interactions between systems, and especially side effects that can affect multiple systems? Because of those, the systems can't really be considered truly independent, can they? Doesn't this cause complexity to go through the roof?
In some ECS in Rust (like Specs) there is a concept of a “resource” for this. System declare their use of resources, which allows the scheduler to order them.
Re: A Simple Entity Component System (2019)
#20ECS is a one of the possible designs of what we usually call "the gamestate" that is the dynamic structure that holds the game world simulation. But the origin of ECS is Data Oriented Design, also known as DOD, that emerged as a reaction to the bad properties of OOP. DOD is more general and IMHO more interesting than ECS. I have not yet seen a satisfying implementation of ECS, it can be extremely fast compared to OOP…
I agree - I have looked into a 2 or ECS implementations, and they either seemed awkward, or brought in a bunch of other concerns I did not care about, and in the end decided to roll my own for some games I was building. It was pretty simple in the end. Dependencies definitely became a bit lengthy in some cases, but I didn't hate that, in that it makes the coupling explicit.
I think that systems should be updated in a very explicit order, so that dependencies are easier to manage.
And for the multithreaded usage, a parallel_for can be used to update systems.