Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualJuliean

Posted 07 April 2013 - 06:50 AM

I have a couple questions regarding entity-component systems. From my reading, it seems that components are to be "data only". Does this mean they should not contain any functions? Say, for instance, I have a "movement" component. This would be given to entities that are able to move, and it would contain variables such as speed, acceleration, max speed, etc. Would it not make sense to give this component the functions that deal with with collision detection and updating position?

 

There are different ways to implement that. One older implementation would be using components that do also implement logic and function, while it is suggested to store the data in the entity itself (though I wonder how that might work, anyways). The other solution is really having the components be just data containers, and have the logic handled by systems. Systems usually search for entities with a given set of components - transform and material for a render system, bounding volume and mass for a physics system. These are just examples, I would suggest you to break systems up a bit more, plus an advanced physics system might better not use entities at all, but have the entities store some reference to a physics body instead and have a system that syncs those.

 

 

Second question. This entity-component system is aimed to replace the inheritance structure of traditional OOP. Does this mean inheritance should be avoided all together when using such a system, or are there cases where it can be used to create a sort of hybrid system? I can imagine using inheritance with the components themselves (such as when some objects require different types of physics calculations).

 

Case and point, with a clever entitiy-component-system system you will not need any or much inheritance at all. What for? Would you inherit components, to add some sort of additional data? Make another component instead. Would you inherit systems, to add some sort of behaviour? Make another system instead. The only good reason to use inheritance in such a system is if you wanted to restrict some components so that each entitiy can only have eigther one of them. Then you would make something like a "BaseLight" component without any data at all, and derive your actual type of light from it. I'm not so sure if this would make sense eigther, while this would work excellent from theory in my implementation, pulling out the special data might be a problem. It would probably require some sort of type attribute for the BaseLight component and a switch statement to determine the actual type. Not very pretty, if you ask me. So no, after all, no real need for inheritance here, unless you REALLY want to programmatically restrict some components in a 1:N relationship (this would work in my implementation since every component gets a certain ID associated with it, thats the key with whom they are stored to the entity - if I'd derive from a BaseXXXComponent, all childs would get that same ID to, so only one of them could be assigned to an entity at the same time).


#1Juliean

Posted 07 April 2013 - 02:12 AM

I have a couple questions regarding entity-component systems. From my reading, it seems that components are to be "data only". Does this mean they should not contain any functions? Say, for instance, I have a "movement" component. This would be given to entities that are able to move, and it would contain variables such as speed, acceleration, max speed, etc. Would it not make sense to give this component the functions that deal with with collision detection and updating position?

 

There are different ways to implement that. One older implementation would be using components that do also implement logic and function, while it is suggested to store the data in the entity itself (though I wonder how that might work, anyways). The other solution is really having the components be just data containers, and have the logic handled by systems. Systems usually search for entities with a given set of components - transform and material for a render system, bounding volume and mass for a physics system. These are just examples, I would suggest you to break systems up a bit more, plus an advanced physics system might better not use entities at all, but have the entities store some reference to a physics body instead and have a system that syncs those.

 

Second question. This entity-component system is aimed to replace the inheritance structure of traditional OOP. Does this mean inheritance should be avoided all together when using such a system, or are there cases where it can be used to create a sort of hybrid system? I can imagine using inheritance with the components themselves (such as when some objects require different types of physics calculations).

 

Case and point, with a clever entitiy-component-system system you will not need any or much inheritance at all. What for? Would you inherit components, to add some sort of additional data? Make another component instead. Would you inherit systems, to add some sort of behaviour? Make another system instead. The only good reason to use inheritance in such a system is if you wanted to restrict some components so that each entitiy can only have eigther one of them. Then you would make something like a "BaseLight" component without any data at all, and derive your actual type of light from it. I'm not so sure if this would make sense eigther, while this would work excellent from theory in my implementation, pulling out the special data might be a problem. It would probably require some sort of type attribute for the BaseLight component and a switch statement to determine the actual type. Not very pretty, if you ask me. So no, after all, no real need for OOP here, unless you REALLY want to programmatically restrict some components in a 1:N relationship (this would work in my implementation since every component gets a certain ID associated with it, thats the key with whom they are stored to the entity - if I'd derive from a BaseXXXComponent, all childs would get that same ID to, so only one of them could be assigned to an entity at the same time).


PARTNERS