I was reading about Entity systems, they look great, but I think they cannot handle all the work. The definition of entity system is

-System (logic)
-Entity (a number)
-Components (Data)

When I need complex Logic Isn't more worth using "logic bricks"? (for example I see hard implement a different AI for each component with a single system. A composite behaviour tree looks much more natural to mee with all the states implemented by separate classes).

The same applies to Animation System. Every scene node potenially animates in a different ways, and the only logical way to me to implement an animation is with a new class with a common interface.

For example If the system accepts only keyframes and bones for animation, I can't use the system for example for syncronize that particular animation with an event, doing that will require dedicated code in the AnimationSystem for what probably will be only a isolated case. Another approach so would be using a SynchroAnimationSystem only for that particular AnimatedComponent (from an entity point of view). But that will seems obese to me, since on long run there will be zillion Systems and making systems communicate within them will get harder.

So I start see limits:

Overgrowing systems (lot of code for particular cases in the same class) <---> many systems

Also certain things works better as behaviour trees (for example a Chain of Responsabilities, or State Driven logic) I see hard to make them become Entities system.

I've been thinking about this Problem, too, but I believe I've found a Way to solve ist: The Strategy Pattern.
Yes, ist is a tiny violation of the Paradigm, but I don't see any disadvantages. There would be two ways to go about ist:

1. Have an AI Component that has the Fields it needs (Aggro List, ...) and additionally,it has a function pointer to the ai subroutine it uses.
2. Have an "ExtendedFunctionality" component that has a vector of std::functions that are to be executed each frame. One being the AI routine..

These functions take their entity as parameter (imagine it being the this pointer), and then do their magic without virtual functions and inheritance

I'm aware this breaks the "No Logic in Components" rule, but it's the most sensible thing i can think of.
Maybe someone else knows better tho...

I'm not sure where this rule of "no logic in components" comes from because it makes no sense to me. Logic needs to go somewhere, so if it doesn't go in components, where does it go? As yet, I've not seen a good argument for behaviours and components being separate, other than vague claims that separation is good therefore separate logic and data is good.

[quote name='Inferiarum' timestamp='1342806244' post='4961384']
if you put logic and data into one component the logic inside the component can only use the data which is also inside the component. That means you have to implement a message system to send messages between components or something similar. And there will be a lot of messages.

But what if you make the components self sustained, so they don't have to access data from other components? This can of course mean moving of more data.
[/quote]
That's not really possible. How does your graphical component know where to draw itself? It would need to know it's location (typically held in a physics or position component), and it would need ot know where the camera is (ie, the center of the screen in world coords). There's tons of other examples too.

Or do you mean the order of updates to data in components depends to data in other components? You'd have to order the updates anyway, either in logic in system, or by building ordered update of components so no stale data is accessed.

Also, surely a system only access the components in it's own domain, and passes messages to other systems?
[/quote]
A System would access whatever components it needs. Typically, it will use components within one entity, but what happens when a bullet hits your player? A System runs, sees a bullet has hits a player, it has to be able to access the bullets damage component, and the Players health (and Armor) component to know how much the player has been hurt.

The way I see it, you don't want components to communicate to each others, becouse that would be logistic nightmare. And you don't want to put all component's logic in one system, becouse you'd have one system per component type (or one massive system per multiple component types). Maybe some kind of subsystem, recurse the general idea.
[/quote]

I'm guessing you've never really tried a entity/component based system or else you'd understand the issues. I created one where the Components held the data and logic, and I'm moving to one where the System does all the logic.

Check out my dev journal (in my sig). My older posts go through my old Component system, and my latest ones has the new system. Check them out to see how I do it there.

So for example how do you translate a State Driven Logic into an Entity system? Each state has its own logic, should that mean to have 1 different system for each possible state?

1. When I need complex Logic Isn't more worth using "logic bricks"?
   
2. Every scene node potenially animates in a different ways, and the only logical way to me to implement an animation is with a new class with a common interface.
   
3. I can't use the system for example for syncronize that particular animation with an event, doing that will require dedicated code in the AnimationSystem for what probably will be only a isolated case.
   

1. The components are supposed to be the logic bricks. Regardless they contain logic or not, some code, somewhere will have to associate behavior to them. Therefore, there must be an association between a component and a behavior.
   
2. I don't see many ways of animations. It's either vertex animation or hierarchical transforms and those are basically orthogonal problems. I don't see why a data-driven system should have a problem with that, I have chosen to use a fat interface and so far it didn't cause much issues. What is your exact concern?
   
3. Yes. Of course it depends on your game needs. Do you need particle systems to emit particles that fall down? Probably yes. Do you need their particles to collide against everything? Maybe. Do you need each particle to spawn a light? Probably not. All those cases must be considered and even isolated cases will have to work. In a way or the other. Your example does not quite seem so much of an unique case to me.
   

That means you have to implement a message system to send messages between components or something similar. And there will be a lot of messages.

Not necessarily. How many messages are "a lot"? Enough to erode performance I guess. Unreal engine has been message-based for a while and I think it takes about 5% of execution time (albeit it's not component-based).

So for example how do you translate a State Driven Logic into an Entity system? Each state has its own logic, should that mean to have 1 different system for each possible state?

Of course not. You provide a state only to manage the "core" behaviors which make sense at system level. Other details are left to implement by the user (that is, the entity using the system).

So for example if you want to chain 3 animations, don't write a [font=courier new,courier,monospace]ChainingAnimationSystem[/font]. Rather, send an [font=courier new,courier,monospace]EndAnimation [/font]event and leave the entity itself starts the new animation.