As long as you call it an Entity I want to inherit from it. Not sure why, it just seems reasonable. If you call it something else I would consider using containment instead though. I guess it boils down to what an entety is.
I mean, if it contains a few general virtual functions or variables that obviously apply to any object in the game universe I would intuitively inherit from it and be on my way
"Simpler" component/composition entity system
Quote:Original post by pulpfistIt sounds like you don't understand, or haven't internalized, the isomorphism between inheritance and composition.
As long as you call it an Entity I want to inherit from it.
C++ allows for very run-time efficient, yet cumbersome implementation of entity systems. Just like everything, C++ can do it, it's just clumsy and fraught with peril.
Good (mainstream) languages to utilize such concepts include javascript, Python, Lua. They might not offer strict canonical entity system, but are much more suitable for ad-hoc composition.
With adequate experience the above can be integrated with C++ back end to bring best of both worlds. Computationally heavy tasks and important memory management is done by C++ while users interact only through simple API.
Yet even then, any useful system of this type will probably expose most of functionality through a non-programatic editor where components are simply wired together and their properties set via property sheets. This adds the extra burden of implementing such tool as well as the need to provide necessary functionality in some pre-packaged repository.
Personally, for hobbyst projects such systems are good on surface, but require considerable understanding of basic relationships between systems. While they are flexible, just throwing entities without planning out and understanding the basic building blocks will merely result in a mess.
This is partly the reason why there is a distinct lack of good overview articles on the topic. The basic concept is simply (just have a map or dictionary), but effective implementation is far from trivial and very domain specific, both with regard to functionality as well as performance.
BTW: the languages mentioned above in this particular case are not only not slow, but will perform *much* faster than majority of C++ based implementations.
Good (mainstream) languages to utilize such concepts include javascript, Python, Lua. They might not offer strict canonical entity system, but are much more suitable for ad-hoc composition.
With adequate experience the above can be integrated with C++ back end to bring best of both worlds. Computationally heavy tasks and important memory management is done by C++ while users interact only through simple API.
Yet even then, any useful system of this type will probably expose most of functionality through a non-programatic editor where components are simply wired together and their properties set via property sheets. This adds the extra burden of implementing such tool as well as the need to provide necessary functionality in some pre-packaged repository.
Personally, for hobbyst projects such systems are good on surface, but require considerable understanding of basic relationships between systems. While they are flexible, just throwing entities without planning out and understanding the basic building blocks will merely result in a mess.
This is partly the reason why there is a distinct lack of good overview articles on the topic. The basic concept is simply (just have a map or dictionary), but effective implementation is far from trivial and very domain specific, both with regard to functionality as well as performance.
BTW: the languages mentioned above in this particular case are not only not slow, but will perform *much* faster than majority of C++ based implementations.
Author
Quote:Original post by mrspeaker
I've been reading everything I can find on component systems (It feels like annnny second now it's going to click!) but I'm struggling to understand some of the implementation details. (Does anyone know of a simple (perhaps the most simple!) implementation of say, a pong game or even just a demo?)
The part I am stuck on at the moment is: does each component have to know how to deal with every single "type" of entity? For example, if you have MovementComponent which updates each entity... how do assign the algorithm for the different types movement? When set the component up for an entity do you give it a type... for exampleand do something like this for each entity inside it's update method?entity.addComponent(Movement, MovementType.WALKING);Then if you had a CollisionComponent how would you make rules like: "If the current entity a player and it collides with an entity of type enemy then die, but if it collides with enitity type wall then stop..."switch(entity.MovementType) case MovementType.FLYING: entity.y--;entity.x++; case MovementType.WALKING: entity.x++ case MovementType.CIRCLING: entity.x = sin(entity.x++)... etc?!
It seems like every component would need to know about every entity type to implement rules? Is that right?
I would personally have either a FlyingComponent or something. Or if it was all under MovementComponent, then I guess you could either have:
entity.movementComponent.Circle();or:entity.movementComponent.SetMovementType(FLY);@the 2nd one, then have SetMovement type call Fly() or Walk() or similar, I guess.
Let's look at this from a more practical angle: what kind of game are you working on? Does it contain a lot of different characters? Do they have a lot of unique abilities? In short, what are your requirements?
The most simple approach that I can think of would be to simply use a member variable for each component that's required, just as your opening post showed. Works pretty well actually:
As for component managers and maps of components, that strikes me as a particularly complex/generic solution. Good for data-driven entity types perhaps, although I would probably start looking into scripting languages by then. Then again, are you sure that such an approach is actually useful for your game, or are you simply over-engineering things? You know, building a lot of infrastructure without actually getting something useful done?
The most simple approach that I can think of would be to simply use a member variable for each component that's required, just as your opening post showed. Works pretty well actually:
class Character{ Sprite sprite; CollisionBody collisionBody; update() { // run logic // synchronize sprite with collision body }}As for component managers and maps of components, that strikes me as a particularly complex/generic solution. Good for data-driven entity types perhaps, although I would probably start looking into scripting languages by then. Then again, are you sure that such an approach is actually useful for your game, or are you simply over-engineering things? You know, building a lot of infrastructure without actually getting something useful done?
Quote:Original post by SneftelQuote:Original post by pulpfistIt sounds like you don't understand, or haven't internalized, the isomorphism between inheritance and composition.
As long as you call it an Entity I want to inherit from it.
I read OP's post again but I can't see that my comment is irrelevant. He said he was looking for something basic. Neither can I see that isomorphism is the only possible direction for this discussion.
...or do you mean it as a joke?
edit:
It does sound interresting. Can you elaborate?
[Edited by - pulpfist on November 26, 2009 4:48:51 PM]
Quote:Original post by pulpfistUsing inheritance/virtual functions for the purposes of code re-use is like, so totally 1990's ;)
It does sound interresting. Can you elaborate?
The reason component systems have become so popular in games lately, is because composition (not inheritance) is the right tool to achieve code re-use and flexible designs.
Quote:Original post by HodgmanQuote:Original post by pulpfistUsing inheritance/virtual functions for the purposes of code re-use is like, so totally 1990's ;)
It does sound interresting. Can you elaborate?
The reason component systems have become so popular in games lately, is because composition (not inheritance) is the right tool to achieve code re-use and flexible designs.
I see. I don't really have a problem with that. Rather, I got the feeling that there was some subtile difference between the two, related to isomorphism.
Anyway, thanks for clearing up the issue
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
