Jump to content

  • Log In with Google      Sign In   
  • Create Account


Entity VS Behaviour


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 DemonRad   Members   -  Reputation: 290

Like
0Likes
Like

Posted 20 July 2012 - 03:21 AM

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.

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!


Sponsor:

#2 Codarki   Members   -  Reputation: 462

Like
0Likes
Like

Posted 20 July 2012 - 05:45 AM

Good topic, I have a question. Why can't the component include logic?

#3 Xelvair   Members   -  Reputation: 262

Like
0Likes
Like

Posted 20 July 2012 - 10:12 AM

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

#4 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 20 July 2012 - 10:42 AM

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.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!

#5 Inferiarum   Members   -  Reputation: 723

Like
0Likes
Like

Posted 20 July 2012 - 11:44 AM

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.

On the other hand, if the Logic is in several system outside of the entity, any of those systems can access an arbitrary number of data components and operate on them, reducing the messaging overhead. I guess there i also less boilerplate code but that probably depends on how you implement your system.

edit: concerning the implementation of certain features, you can do it the same way as with a deep inheritance approach. Just separate the logic from the data. In an inheritance based system you inherit from a certain class and add some features. For these features you need additional data fields in the entity. Add these data fields as a component. The additional logic to use this data fields is added in an additional system. Now instead of a deep inheritance tree with maybe multiple inheritance and stuff you can define the behavior of the entity by plugging the different components and corresponding systems together.

Edited by Inferiarum, 20 July 2012 - 11:55 AM.


#6 Codarki   Members   -  Reputation: 462

Like
2Likes
Like

Posted 20 July 2012 - 02:13 PM

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.

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?

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.

#7 BeerNutts   Crossbones+   -  Reputation: 2550

Like
1Likes
Like

Posted 20 July 2012 - 02:54 PM


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.

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?

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.


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.
My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#8 DemonRad   Members   -  Reputation: 290

Like
0Likes
Like

Posted 21 July 2012 - 01:12 AM

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?

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!


#9 Krohm   Crossbones+   -  Reputation: 2956

Like
0Likes
Like

Posted 21 July 2012 - 03:17 AM

  • When I need complex Logic Isn't more worth using "logic bricks"?
  • 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.
  • 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.

  • 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.
  • 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?
  • 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 ChainingAnimationSystem. Rather, send an EndAnimation event and leave the entity itself starts the new animation.

#10 Inferiarum   Members   -  Reputation: 723

Like
0Likes
Like

Posted 21 July 2012 - 03:30 AM

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?


I guess you store the state in some component and do the logic how you would do it for any other kind of approach.

#11 DemonRad   Members   -  Reputation: 290

Like
0Likes
Like

Posted 21 July 2012 - 03:40 AM

Isn't that hackish way to accomplish that? You have the additional problem to keep correct mapping of logic with components. At this point Entity system I think is abused, it sounds like somekind of overcomplication (probably I'm wrong)

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!


#12 BeerNutts   Crossbones+   -  Reputation: 2550

Like
0Likes
Like

Posted 21 July 2012 - 10:45 AM

Isn't that hackish way to accomplish that? You have the additional problem to keep correct mapping of logic with components. At this point Entity system I think is abused, it sounds like somekind of overcomplication (probably I'm wrong)


There are many ways to accomplish this with an entity component system. I don't know why having State stored in a component is "hackish." It's just a different place to store the state. The system could be setup as you would normally handle different states. If that's "hackish" then however you've previously been doing it must be hackish too.

Of course, I might look at having different Components for the different states, depending how may there are and what they represent. I'm not sure what would be the issue if you even went to the level of having Idle, Running, and Jumping Components for your player. These could be processed by different System, and that's how the states are processed.

I don't have a lot of experience with these systems, but I've done one game with a ECS, and now I'm working on my next, and I figure I'll be learning more as I go on, see what works well and what doesn't.

Edited by BeerNutts, 21 July 2012 - 10:46 AM.

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#13 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 21 July 2012 - 12:29 PM


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.

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?

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.


That's actually a good argument. I can already think back to times when the message passing overhead inside an object has gotten to silly levels.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS