So I’m not familiar with the ECS style of doing things - what’s the granularity of an entity in this system? Does that go down to a point? quad? mesh? The way I understand the examples, lights and meshes are definitely a kind of entity, but could be subdivided?
An entity is just a container of components, I believe points and meshes are generally components contained by an entity. i.e. an enemy entity might contain a location component (point), and a body component (mesh).
The way I think of it is that entities generally map to objects in OO, components to fields, and systems to methods. The big difference is that systems are not bound to entities, and instead each system queries the set of entities to find ones to act on.
I think one of the better ways to understand the value of storing entity fields as components is through concurrent systems. The ECS model, despite being used heavily in OO languages, is anti-OO. With OO data modelling you would need two systems that each want to change an entity to run serially or use some typing of locking because your unit of addressability is the entity object. By storing entity details in components, which are not part of the entity object, a system can address just one type of component for an entity (or set of entities) while another system can address a different component for the same entity. Since the queries are disjoint and neither system has a reference to the entity object the systems can run concurrently without worrying about conflicts.
In some of the bevy examples a system will pass a component back to the engine to get a reference to the entity. If you dig deeply enough you’ll find that the entity reference is an ID rather than a memory reference. This is another lens into the anti-OO aspect of ECS. I’m not familiar with the specific storage techniques used by bevy but at a conceptual level you can think of entities as a table in a relational DB with a single column that is also the primary key. Each component in ECS would then be a different table with a foreign key reference back to the entity. This sparse storage is another way to see the utility of ECS and IMO why it has been popular in C++ game studios. In C++ every entity of a given type would need to store fields for every value that would ever be needed by any entity of that type. If you had a class RpgNpc and you wanted to track whether a player had met the NPC you could easily add a boolean hasBeenMet field to the class. This would incur a storage cost for all NPCs even at the very beginning of the game. With ECS you have the overhead of tracking the HasBeenMetComponent values but you only have those components in memory for NPCs the player has actually met, which would be zero at the beginning of the game.
What are the concerns about MPL that warrant changing to MIT? Maybe I’m biased, but I really don’t like MIT for how permissive it is because it’s the equivalent of public domain, and MPL has to me been the perfect alternative to the more restrictive GPL family of copyleft licenses.
It says in the article that some potential users were avoiding customizing wgpu to make it work on the Switch because the MPL is copyleft, which would require those modifications to be distributed in source form. I’ve never worked on the Switch but it seems reasonable to infer that there is some binary linking going on that would make the combined wgpu + proprietary code the derivative work and thus require distributing the source code for the proprietary component too.
The MPL-2.0 is file-based copyleft. There’s no way for linking or any kind of automated combination of works to result in the license extending outside of the individual files licensed under it.
So I’m not familiar with the ECS style of doing things - what’s the granularity of an entity in this system? Does that go down to a point? quad? mesh? The way I understand the examples, lights and meshes are definitely a kind of entity, but could be subdivided?
An entity is just a container of components, I believe points and meshes are generally components contained by an entity. i.e. an enemy entity might contain a location component (point), and a body component (mesh).
The way I think of it is that entities generally map to objects in OO, components to fields, and systems to methods. The big difference is that systems are not bound to entities, and instead each system queries the set of entities to find ones to act on.
I think one of the better ways to understand the value of storing entity fields as components is through concurrent systems. The ECS model, despite being used heavily in OO languages, is anti-OO. With OO data modelling you would need two systems that each want to change an entity to run serially or use some typing of locking because your unit of addressability is the entity object. By storing entity details in components, which are not part of the entity object, a system can address just one type of component for an entity (or set of entities) while another system can address a different component for the same entity. Since the queries are disjoint and neither system has a reference to the entity object the systems can run concurrently without worrying about conflicts.
In some of the bevy examples a system will pass a component back to the engine to get a reference to the entity. If you dig deeply enough you’ll find that the entity reference is an ID rather than a memory reference. This is another lens into the anti-OO aspect of ECS. I’m not familiar with the specific storage techniques used by bevy but at a conceptual level you can think of entities as a table in a relational DB with a single column that is also the primary key. Each component in ECS would then be a different table with a foreign key reference back to the entity. This sparse storage is another way to see the utility of ECS and IMO why it has been popular in C++ game studios. In C++ every entity of a given type would need to store fields for every value that would ever be needed by any entity of that type. If you had a class
RpgNpcand you wanted to track whether a player had met the NPC you could easily add a booleanhasBeenMetfield to the class. This would incur a storage cost for all NPCs even at the very beginning of the game. With ECS you have the overhead of tracking theHasBeenMetComponentvalues but you only have those components in memory for NPCs the player has actually met, which would be zero at the beginning of the game.What are the concerns about MPL that warrant changing to MIT? Maybe I’m biased, but I really don’t like MIT
for how permissive it isbecause it’s the equivalent of public domain, and MPL has to me been the perfect alternative to the more restrictive GPL family of copyleft licenses.It says in the article that some potential users were avoiding customizing wgpu to make it work on the Switch because the MPL is copyleft, which would require those modifications to be distributed in source form. I’ve never worked on the Switch but it seems reasonable to infer that there is some binary linking going on that would make the combined wgpu + proprietary code the derivative work and thus require distributing the source code for the proprietary component too.
The MPL-2.0 is file-based copyleft. There’s no way for linking or any kind of automated combination of works to result in the license extending outside of the individual files licensed under it.
Oh I guess I missed that part. Thanks for the explanation!