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?

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).

Third question. In implementing an entity-component system, what does this actually do to the compiled program? As opposed to a traditional inheritance structure, does the compiled program take up more hard drive space? Does it take more processing power to run? Is there more overhead? If so for any of those, by how much?

Edit: Fourth question. What would warrant a project to make use of an entity-component system over a traditional inheritance structure? Is it something that should be used without exception, or is it really only beneficial for games with a large scope and with many programmers working on it?

My understanding is that components really only had 'get' and 'set' style functions. It is the Systems that are aware of how to manipulate such data. In my current project (still planning it) I simply have three base interfaces: ISystem, IEntity, and IComponent.

I store your 'movement' component in a 'CSpacialComponent' class that contains both an entity's spacial position but it's velocity, and acceleration. It also stores the same values for the object's rotation in Euler angles (that is angular displacement, velocity, and acceleration).

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).

Hello,

Everyone had pretty good inputs on the topic. I just want to emphasize that components should have functions... I always see people saying that components should be purely data related without any functions. It's what the functions do that needs to be addressed. If you are sticking with the more "recent" approaches to building a component-entity system, then functionalities of a component should not posess logic that modifies the data directly. I do not see any drawbacks of having functionalities that help setup the data. For example, if you have a "renderable" component, perhaps one of the functions parses a file to create the vertex/index buffers. If you have a "transformable" component, you could have functions that can rotate, translate, scale the underlying matrix data. These functions help set the data up. The logic on the other hand would be handled by a system, which would most likely call upon those component functions to modify the data.

I do not see any drawbacks of having functionalities that help setup the data. For example, if you have a "renderable" component, perhaps one of the functions parses a file to create the vertex/index buffers. If you have a "transformable" component, you could have functions that can rotate, translate, scale the underlying matrix data. These functions help set the data up. The logic on the other hand would be handled by a system, which would most likely call upon those component functions to modify the data.

At least your first example vialotes not only the http://en.wikipedia.org/wiki/Single_responsibility_principle, but would make your "renderable" component quite inflexible. If you want to change your file format, you have to change the renderable component, also if you want to switch the underlying API. But most of all, the "renderable component" should neigther be responsible for loading a file, nor a texture, nor anything else. That is the responsibility of your graphics libary, if not even a special file loading libary.

As for the functions that rotate, translate, scale... except for the rotation, that is not even necessary. These functions won't do nothing more than modifying the 3 respective scalation/translation fields of the matrix, at least for the rotation it is a bit more complicated so that would make the most sense, if any. I also prefer to have "transform" seperated into components for translation, rotation and scale, and store the values arbitrary, but thats probably a matter of choice.