I'm making a game framework using allegro5. I have read many article about entity systems and i decided to go "component aggregation" method. And i did some search on google but can't found any usage examples of this method. I only found an entity framework called "artemis"(for java) but in its classes there is no method like "GetComponent". Entity creation part is ok

Entity wall;
wall.AddComponent( new PositionComponent() );
wall.AddComponent( new SpriteComponent("wall.png") );
wall.AddComponent( new RenderComponent() );

But how can do actions? For example how can i move my entity etc.

Thanks

Here's how my latest component-based framework works. It's written in D, but in principle should be doable in C++ too. Pseudo code:

One of the beneficial part of making an entity system is avoid having methods inside components.

Well yhea, that's an important one too.

Well, an entity system as the name suggest is based on entities and systems.

Entities are just data. An entity is composed by components, and at the same time those components have their own systems (separated).

Each component has its own system which controls it. And each system is dedicated to just one component.

Ideally one entity should have just one system, but that's not practical because you would need to rewrite too much code sometimes, for that reason each entity is able to have multiple components.

But at any time you should be able to split components as you want. Just create a new system to handle that part and that's it.

Therefore, having methods inside components would mix everything up.

If you have methods inside components you're almost inside the OOP world and that's not how an entity system works. You could even get tempted to inherit some class and that's it, you have screwed the whole system...

I remember the days when entity systems were systems that handled entities.
Anyway, your post completely ignores the question of why components that do their own logic are essentially bad and why they and subsystems are mutually-exclusive.

Maybe we're just not talking about the same thing? When I (and I assume most everyone here) say component, we mean just a single bit of functionality of a larger object (entity). Like say the position, velocity or collision. Instead of combining them all into one single object, your entity class just holds a list of components, and those components each take care of one of those properties.

How is that even useful? You still have the data and code for them stored elsewhere, so those are the actual entities. That list of ids are really just indexes or tags for the real entities.

Well, to me that's wrong. Position an velocity are components, but collision is not a component, because collision is something that happens and not just data. In case you mean collision as data describing how to perform collision detection then it's component, but if you mean collision as checking for collision detection then to me that is not a component.

It's useful when you create the entity system as the blog I posted earlier (which I said I'm not going to explain here again), now I think I have improve the system a little bit, but maybe I haven't.

The ES in the blog execute "queries" to get all the components of an entity, and perform actions on that data and for doing so you need an ID. Now, since each system is made to process data of a specific component/components I have decided to create a map for each component in my videogame, that way I don't have to execute the "queries" all the time. I actually made that comment on the blog and guy told me that I should prove it, at least he didn't say a big NO! hehehe.

Yep indeed, but with no methods is better... To me, though.

Good...

Yes, and now you feel better.

My god!

The thing I don't like about explicitly separating data from logic is that the representation of data can be logic dependent, and once you commit to a certain data representation you are left out dry if it doesn't allow what you want with it.

For example, say your entity needs a position... for most entities you'd need an X and a Y position, so you make a data component that other systems can use. Now imagine an entity that rotates around a point (let's say it's the origin). So, you create a new data component with an angle and a radius and a system to update the X and Y given the angle and radius.

Now, there are two issues with this example:

1. What's the point of the X and Y variables in the rotating entity? Angle and radius already determine the position of the entity and X and Y are vestigial.

   
   

2. Even though the angle/radius data component is separate from the associated system, they are still tailored to each other and the data was added because of the system's requirements and not vice-versa. Ultimately you are still tying data and system together.

Now in my system the position component would be an interface that could be implemented by something with an angle/radius or an X/Y.

Here's a different example... again with positions. Say you're using an external physics engine... that engine already takes care of the positions of different entities. How would you use that external engine in a component system? If you're just using the data components, you'd have to use those vestigial X/Y variables. How about making a dedicated physics component? Well, in that case you're stuck having physics enabled for every object, even things that don't need to have physics (e.g. lights). If you use interface components then you don't have an issue: the physics component would simply implement the position interface.

Yay I like problems.

Ok if I have an entity1 that has a position, a static position and then I draw an entity (entity2) near to entity1, entity1 should start rotating around entity2.

In this case my component for entity1 would be just a boolean, something like bool gravity = true and my entity2 would have another boolean something like bool point_of_gravity = true.

So I create a system called void perform_point_of_gravity() and another one called void perform_gravity().

void perform_point_of_gravity() will search all the entities inside the std::map<int, GRAVITY_COMP*> and execute the algorithm to attract the entity to the entities inside the std::map<int, POINT_OF_GRAVITY_COMP*> it doesn't matter what kind of entity it is, if it has a ´GRAVITY_COMP´ the system will start changing its X and Y coordinates.

This function only attracts entities while the entity itself remain static, If we add the same GRAVITY_COMP to both entities and create another system more generic called void perform_gravity() then the two entities would start trying to rotate around each other.

There are other system that need that data, the rendering system, or the collision detection, I'm actually trying to make videogames not trying to figure out the most bizarre situations.

There are system that use the data for different purposes than other system. If one system needs more data just to actually make that system work then you just add another component to the entity to that specific system. And indeed the data is most of the time made for one specific system, but it doesn't have to be all the time. Just like when you create methods inside and object which performs operations in that specific data of the object.

I think the point of having the methods in a separate system class is because this way such function can perform an operation that operates on more than one component (for example, a CollisionSystem may work with polygons and circles, and allow any kind of combination between the two, and at the same time being able to add new kind of objects easily, because all the collision code is in a single place). Having the collision code in a Polygon class doesn't make that much sense either, since Polygons may be used for other things where you don't want any kind of collision detection.

Also, refactoring is easier: if you want to split a component in 2 different ones (or join 2 components into one), you only need to update the system(s) that uses that component without altering code in any other place. Well you may need to alter the creation function if the model is hard-coded.

Also, if you go to other languages (like java or c#) where all methods are "virtual" (or SiegeLord's method using interfaces since they'll need to be virtual (that WireUp method need to be virtual or things won't work )), having the methods in the components (which may be thousands of instances of each one) will have both a bigger memory footprint and performance hit than if it's on a system class (since there's only one instance of each system).

At least, that's what I get after reading AMCerasoli's link, and this one. Both seem to agree about what an Entity System is. What you people are describing is an OOP design with some component based thing on top of it, which doesn't mean it's a bad thing, but it's not an Entity System. From the reads it looks like a pure Entity System is mostly useful for bigger projects, with several people working on it and probably not that useful for small/medium projects.

Here's another implementation. This one doesn't even have an Entity class, entities are just integer ID's. -(edit: after reading that page a bit better, it's actually a full programing language that uses the Entity System paradigm)- (edit2: I was reding something else and mixed things up, forget the edit ).

Disclaimer: this is my understanding, but I've never used this method. Although I want to try it.

Because it has an offset from the world origin. Or maybe it's a rotating light. If you don't want your light to be transformable, don't add a transformation component to it.

Yeah. That horrible god-object is called a transformation matrix.

Overkill in the sense that it took me a minute to understand what you're even talking about and given your examples, I seriously doubt it solves any problems that aren't solvable by simply having sane components.

That's a perfect example of when subsystems are useful. I use subsystems when they're convenient and logic inside components when that's convenient, in the same projects. I don't really see the problem.

Virtual tables. Each instance need its own virtual table, and each method is an extra entry on each object's virtual table.

What data duplication? in one of the steps it shows how that is removed, there's no duplicated data in the final implementation.