6 ms·

A definition of "ECS" would have been nice.

by x3n0ph3n3 8y ago

maxxxxx 8y ago
"Entity-Component system"?
- HelloNurse 8y ago
  Plural "Systems" in ECS architecture are the separate explicit and implicit modules (functions, objects, processing passes, etc.) that do something with the data represented by Entities and Components, and thus represent the third equal leg of the architecture, like in other three letter acronym architectures (MVC, BDI...); it isn't just an architecture organized as a system (singular) of Entities and Components, even if some kind of framework to manage them is necessary. Systems could be managed by a framework too, for example to process them automatically in a correct order.
epage 8y ago
To add a quick summary to the given acronym expansion, I think of Entity-Components as a native, in-memory database where Entities are your Primary Keys and Components are your Tables. Systems are a way of organizing and running operations on your entities over time. native: native to your programming language, ie no serializing / deserializing types
gpm 8y ago
Entity-Component-System (Which I think is more correct than Entity-Component system) It's a pattern of organizing data and code that consists of: Entities: Conceptually these are like objects, in memory they might just be an index. Components: Conceptually these are like fields on objects, they can typically be added and removed unlike normal fields. If entities are being represented as index's, each different type of component is generally stored as some form of Map<Entity, Component>. Systems: These are where you store your logic, they typically iterate over all entities with a given set of components and do something. For example iterate over all entities with a position and velocity components, and do position += velocity * dt.
fenomas 8y ago
Here's my simple explanation. Making a game with object hierarchies, you might do the equivalent of this: monster = {} // create an entity monster.hp = 10 // give it properties monster.pos = [0,0,0] Using ECS, you instead do the equivalent of this: currID = 1 // ECS init hpData = {} posData = {} id = currID++ // create an entity hpData[id] = 10 // give it properties posData[id] = [0,0,0] Obviously neither version is really implemented that way, but hopefully it shows the key insight - instead of storing properties on the object they describe, you store them in tables full of like data, keyed by the ID of the object they describe.
- reificator 8y ago
  Showing the how without showing the why is probably not helpful IMO. Why is important here. Using ECS is somewhat like treating your game state like a normalized database. It lets you perform operations on all the items of a certain type at once. Say in my game I need to recenter my origin on a regular basis. In an open world game, you want to make sure that players don't start to see errors caused by floating point arithmetic, and the further away their position gets from 0, the worse this gets. To fix it, one option is to transform all positions by the same amount to keep the player's absolute position near (0, 0, 0). To do this in the hierarchy style, the code might look like this: (Using JS because I was writing it today so that's where my brain is) var gameObjects = world.getAllGameObjects(); var offset = [-1000, 0, 500]; // Pretend it's a real vector // Iterate through every single object in the game // (Not using foreach or filtering in either example, sue me) for(var gameObject in gameObjects) { // Branch on every game object just to see if it's positioned in the world if(gameObject.position !== null) { // Do what I really wanted to do gameObject.position.add(offset); } } Meanwhile, the ECS version would look more like this: // This can vary greatly based on implementation // I'm going to go with an option that reads easily // This should just give back the list of components, which we'll say is an array. // Lookup time in this fictional system is the cost of a dictionary lookup. var positions = world.getComponents('position'); var offset = [-1000, 0, 500]; // Pretend it's a real vector // Iterate through only the things we care about // Not using map here, sue me for(var position in positions) { // Do what I really wanted to do position.add(offset); } Not only is the second example shorter, but it's also doing a lot less work. We're adding a vector to an array of vectors. No branching, no touching objects we don't care about, nothing extra. Many ECS systems will allow you to filter down to the set of entities that have two or more components at the same time. Obviously more expensive, but still not as wasteful as checking every object or adding an update function to run every tick on every relevant entity. The above code was written just before bedtime and not against a real ECS library or OO hierarchy, so please forgive any obvious errors.

A definition of "ECS" would have been nice.

maxxxxx 8y ago

"Entity-Component system"?

HelloNurse 8y ago
Plural "Systems" in ECS architecture are the separate explicit and implicit modules (functions, objects, processing passes, etc.) that do something with the data represented by Entities and Components, and thus represent the third equal leg of the architecture, like in other three letter acronym architectures (MVC, BDI...); it isn't just an architecture organized as a system (singular) of Entities and Components, even if some kind of framework to manage them is necessary. Systems could be managed by a framework too, for example to process them automatically in a correct order.

epage 8y ago

To add a quick summary to the given acronym expansion, I think of Entity-Components as a native, in-memory database where Entities are your Primary Keys and Components are your Tables. Systems are a way of organizing and running operations on your entities over time. native: native to your programming language, ie no serializing / deserializing types

gpm 8y ago

Entity-Component-System (Which I think is more correct than Entity-Component system) It's a pattern of organizing data and code that consists of: Entities: Conceptually these are like objects, in memory they might just be an index. Components: Conceptually these are like fields on objects, they can typically be added and removed unlike normal fields. If entities are being represented as index's, each different type of component is generally stored as some form of Map<Entity, Component>. Systems: These are where you store your logic, they typically iterate over all entities with a given set of components and do something. For example iterate over all entities with a position and velocity components, and do position += velocity * dt.

fenomas 8y ago

Here's my simple explanation. Making a game with object hierarchies, you might do the equivalent of this: monster = {} // create an entity monster.hp = 10 // give it properties monster.pos = [0,0,0] Using ECS, you instead do the equivalent of this: currID = 1 // ECS init hpData = {} posData = {} id = currID++ // create an entity hpData[id] = 10 // give it properties posData[id] = [0,0,0] Obviously neither version is really implemented that way, but hopefully it shows the key insight - instead of storing properties on the object they describe, you store them in tables full of like data, keyed by the ID of the object they describe.

reificator 8y ago
Showing the how without showing the why is probably not helpful IMO. Why is important here. Using ECS is somewhat like treating your game state like a normalized database. It lets you perform operations on all the items of a certain type at once. Say in my game I need to recenter my origin on a regular basis. In an open world game, you want to make sure that players don't start to see errors caused by floating point arithmetic, and the further away their position gets from 0, the worse this gets. To fix it, one option is to transform all positions by the same amount to keep the player's absolute position near (0, 0, 0). To do this in the hierarchy style, the code might look like this: (Using JS because I was writing it today so that's where my brain is) var gameObjects = world.getAllGameObjects(); var offset = [-1000, 0, 500]; // Pretend it's a real vector // Iterate through every single object in the game // (Not using foreach or filtering in either example, sue me) for(var gameObject in gameObjects) { // Branch on every game object just to see if it's positioned in the world if(gameObject.position !== null) { // Do what I really wanted to do gameObject.position.add(offset); } } Meanwhile, the ECS version would look more like this: // This can vary greatly based on implementation // I'm going to go with an option that reads easily // This should just give back the list of components, which we'll say is an array. // Lookup time in this fictional system is the cost of a dictionary lookup. var positions = world.getComponents('position'); var offset = [-1000, 0, 500]; // Pretend it's a real vector // Iterate through only the things we care about // Not using map here, sue me for(var position in positions) { // Do what I really wanted to do position.add(offset); } Not only is the second example shorter, but it's also doing a lot less work. We're adding a vector to an array of vectors. No branching, no touching objects we don't care about, nothing extra. Many ECS systems will allow you to filter down to the set of entities that have two or more components at the same time. Obviously more expensive, but still not as wasteful as checking every object or adding an update function to run every tick on every relevant entity. The above code was written just before bedtime and not against a real ECS library or OO hierarchy, so please forgive any obvious errors.