I'm having trouble understanding how I would integrate my logic code if I were to implement a pure component-based system (ie, each entity is only a collection of components and nothing else). I can think of many examples where I have an entity which needs to handle some amount of specific logic. The only thing I can do is create a new component which would be tied only to this type of entity. But then I would have a number of components that, really are not components, but just pieces of logic that belong to only a single kind of entity. It feels like this is the wrong approach to take - I thought the idea was to create generic components that you can put on top of any entity. However, I cannot think of any other way to handle this. Can someone give me some pointers?

Quote:Original post by Captain P
Don't over-abstract things. Components are usefull if they cover functionality that's used in multiple entities, but logic that's specific to only one or two entities doesn't need to be put into a component - you can put it into the entities themselves just fine, and if you need that functionality again in another entity, you can always create a component for it and refactor the old entity.

In the end, don't forget your goals. Are you writing a component-based system because you're writing a component-based system, or does it actually offer you specific benefits? First decide what you need, only then you can determine what's the better approach.

I understand what you're saying. But even still, I believe there are those who use architectures in which there is only one "Entity" or "GameObject" class and nothing else derives from it (for example, in Programming Gems 5). So if that were the case, how would you "put it into the entities themselves" if you don't have an actual type of entity to begin with? You don't have any other choice but to make it a component! I was just curious what other people do.

But yeah, I see that it just makes more sense to have actual defined entity types, while each entity can still have its components.

[Edited by - fd9_ on September 17, 2007 4:31:32 PM]

Quote:Original post by Captain P
...logic that's specific to only one or two entities doesn't need to be put into a component - you can put it into the entities themselves just fine...

I don't know what your intended meaning is here. Do you mean:

(a) Derive a subclass from the top-level Entity class for this particular type of entity, and put the specific logic there

or

(b) Put the specific logic in the top-level Entity class

?

If you mean (a), to me it seems that creating an Entity inheritance hierarchy starts down the path that component-based entities are designed to prevent. You start with a couple inherited classes, and over time it ends up growing into the typical mess that these things do (i.e., the "blob" anti-pattern). Also, it makes it more difficult to instantiate entities in a data-driven way by assembling components, since you now have to determine which type of entity to instantiate. You lose that really nice rapid-prototyping ability where you can easily create new entity types just through the data. I think this is definitely one of those things where composition is preferable to inheritance.

I'm going to assume you don't mean (b). Putting logic in the main Entity class that's only used by one or two types of entities doesn't start you down the path to the "blob", it pretty much takes you there in one quick leap.

Personally, I don't see anything wrong with having a component that's only used by one or two entity types. I'd probably implement it as a sub-component in a "logic" or "AI" type. You just end up with a component (or sub-component) that's only used by one type of entity, instead of an Entity subclass that's only used by one.

I completely agree with you about not using a system just to use it. It's easy to get carried away with that, and I've been guilty of that plenty of times. But I think there's substantial benefit to sticking consistently to the component model.

You can design an interface between the game logic components and the engine, or possibly multiple interfaces if necessary. The interface could allow the game logic component to register itself to receive events or regular updates, and it can implement a callback where the logic is actually executed. Each specific entity might have its own logic component implementation, but they can share the interface and you might notice ways to design more generic components after making a few, e.g. maybe a higher level component chooses between two other logic components, each implementing a different behavior, and this could evolve into a sort of state machine.

Quote:Original post by Martoon

Quote:Original post by Captain P
...logic that's specific to only one or two entities doesn't need to be put into a component - you can put it into the entities themselves just fine...

I don't know what your intended meaning is here. Do you mean:

(a) Derive a subclass from the top-level Entity class for this particular type of entity, and put the specific logic there

If you mean (a), to me it seems that creating an Entity inheritance hierarchy starts down the path that component-based entities are designed to prevent. You start with a couple inherited classes, and over time it ends up growing into the typical mess that these things do (i.e., the "blob" anti-pattern).

Also, it makes it more difficult to instantiate entities in a data-driven way by assembling components, since you now have to determine which type of entity to instantiate. You lose that really nice rapid-prototyping ability where you can easily create new entity types just through the data. I think this is definitely one of those things where composition is preferable to inheritance.

I agree with you on the second part, about making it easier to instantiate entities in a more data-driven fashion when you *only* have components to deal with. However, I don't think that deriving from the base Entity class automatically means you'll end up with the "blob" anti-pattern. In the end, it all comes down to having a balance. Why not have the best of both worlds - inheritance and components - as long as you don't go to one extreme or the other? Having a mix of components and inheritance will prevent you from developing the blob, and at the same time it will prevent you from developing crazy types of components.

Quote:Original post by Vorpy
You can design an interface between the game logic components and the engine, or possibly multiple interfaces if necessary. The interface could allow the game logic component to register itself to receive events or regular updates, and it can implement a callback where the logic is actually executed. Each specific entity might have its own logic component implementation, but they can share the interface and you might notice ways to design more generic components after making a few, e.g. maybe a higher level component chooses between two other logic components, each implementing a different behavior, and this could evolve into a sort of state machine.

Quote:Original post by dmatter
Vorpy's suggestion is one solution to this. A similar idea is the use of a ScriptComponent, clearly this component allows an entity/gameobject to be scriptable. This is pretty much the data-driven (in the sense that a script is just data) equivalent of Vorpy's 'logic components'.

Definitely two good suggestions, and something to think about.