Sorry for leaving you alone with the crickets, the last two days have been a bit turbulent for me to say the least.
Thank you for the in-depth explanation, I liked getting a more behind-the-scenes look at how Zay-ES is performing its job.
At this point, I don’t really have any question lingering in my mind - I suppose some would come up as I get working with Zay-ES, if at all.
As stated earlier, I’ll definitely get started working with Zay-ES, using the wiki as my first stop.
And yeah, I think the above post is a good collection of information for anyone. Making an article out of it would likely help a lot of people, probably even with no jME background.
That’s probably the clearest explanation of an ECS that I’ve ever read. Good enough that I could probably implement a (simple) version just based on that post.
Agree, that’s an excellent explanation. I still have a couple of questions, though. As far as I understand, ECS is not only a better programming technique, but also faster than Controls, is that correct? Also:
According to what I read around the internet, that approach works great because of how C++ deals with memory. But since memory is managed differently by the JVM, and considering what was said by @pspeed, I understand that in Java it would be better something like:
entity = class with an index (aka ID), list of components
component = class, no logic, only data
component system = logic + array of entities that contain components (data) of a certain type
I believe that is what Project Valhalla tries to resolve. So a component won’t be a class but a Value Object which is treated like a primitive in the memory. JVM will prefer inlining value objects where feasible. An inlined value object is encoded directly with its field values, avoiding any overhead from object headers, indirections, or heap allocation.
The problem with an entity being a class with a list of all of the components is that you will almost never use it that way. Moreover, now you’ve forced all components to be in RAM all the time. They all must be real objects. All in RAM. And you gain almost nothing by doing this.
Also, most entities won’t have all of the components.
So while we cannot (today) really control how the memory in the VM is laid out, I guarantee you that 50,000 entities with 10 components each is going to be a super ugly heap compared to 10 separate collections of <50,000 components each.
Pulling them together into subset entities for the systems is not particularly expensive (O(1) complexity) and if they were full objects then you would need to break them into subsets anyway.
Also, in an implementation like Zay-ES, it’s optimized to only do it once initially. The subsets are built dynamically after that based on component changes. And while this is an implementation detail, it further drives the point home that “big giant entity classes” not only have no real advantage but potentially have performance disadvantages.
Zay-ES gets some other benefits from the split, too. Some components can be in RAM, some can be loaded dynamically from disk, etc… It’s also really nice for the networking implementation that things operate internally only at the EntityId, EntityComponent pair level.
I was just picking them out as I scratched my head.
I’ve read this multiple times but still don’t understand what it all means. I think that I don’t understand the concepts that make up an ECS and I am putting my cart before my ECS horse.
Just gotta keep learning. Thank you for the detailed write-up it is always super helpful to read conceptual breakdowns like this.
Just wanted to post in case it’s useful to anyone else-
I was bumbling around with the Asteroids project and then I didn’t realize where this link was taking me to
It’s in User Contributions on the wiki and then under Zay-ES Entity System. I didn’t realize there were links to additional wiki pages in here. cool stuff!
