   Component Based Entity Design
  Hi,I want to implement an Entity System for my engine soon, so I happily read this thread: hereBasically I just want to sketch how I plan to implement it and would like to get some feedback. I want to choose an approach where Entitys are rather data structures that aggregate data/components that then get used by specific subsystems.The subsystems observe the components of each entity and have a queue of entities that changed and need to be processed (as described by Lord_Evil in the other thread). This is a first draft I have in mind.Since Entities in my engine should almost only be things placed in the world, this could be my entity class:class Entity{// information to position an entity in the worldEntity * parent;list<Entity*> children;Vec3 relativePos; // relative to parentVec3 absPos; // world positionvector<Component*> components;};I am not sure if it would make more sense to store the parent, absPos etc. part in an extra "SceneNode" Component or not. What do you think?Component:class Component{Entity * owner;// these subsystems get notified if something changes about the component // and get added to the subSystems processQueuelist<SubSystem*> observingSubsystems;};SubSystem:class SubSystem{// list of entities that need to be processedlist<Entity*> processQueue;// list of all registered entitieslist<Entity*> registeredEntities;};On Entity creation you would basically check based on the components to which subsystem each entity needs to be registered.Now that I think about it, if the subsystem does not need to process all the entities, wouldn't it be enough to only have the processQueue list in the subsystem and register it to the components needed on entity creation?It would be great if I'd get some feedback, thanks!   
  Hi mokaschitta,as your location is Hamburg is assume you speak german?You might be interested in the making games magazine (German) this month. There is an article in it about 'Das komponentenbasierte GameObject-System'.http://makinggames.idgshop.deHope this helps you or is at least an interesting read.--GWDev   ;  thanks, that sounds like a good read!   ;  If you're going to have a physics simulation, it's probably a good idea to use that to handle physical relationships and parenting, rather than a scenegraph. If your tires need to be attached to your jeep, the physics simulation should know about that. Graphics only needs the final position.Here's a useful thread.   ;  I'd factor out the position as well as orientation etc. and use a TransformComponent. This component could be used by other subsystems, too, e.g. physics, graphics, etc.The parent-child relation could be expressed by a SceneNode component which then would contain information on the parent and relative transforms.Edit: In addition to theOcelot's post, note that this relationship would just be a spatial or physical one. You might need another component to express logical relationships.Thinking further about the use of the entity as a container I'm currently testing the approach of srapping the entity class altogether and making the entity merely a label (as described in several papers/articles). This would be even more similar to Sneftels approach than my first shot in that subsystems are responsible for creating and maintaining components. Creating an entity would then involve to describe which components are used and which data they'd contain. I'd then call the subsystems to create the necessary components with the given entity id. Inter-component communication would be handled by getting a pointer to the components needed by querying the respective subsystems once. There might also be intermediate components (like the transform component) that contain shared state and are listened to by other components or subsystems.Finding all components for an entity might be more expensive though, but I'll check see if this is often necessary or if it doesn't really matter for just a few queries.As for your processQueue:If the order in which components are processed by a single subsystem is not strictly necessary (e.g. culling might be done out-of-order, rendering might be split into several lists [opaque, transparent, ...] which might be processed out-of-order) a single vector might be better. You'd then swap components in the list to bring all to-be-processed components to the from of the vector and later iterate just over that front part (or if the subsystem needs to process all components anyways, skip the to-be-processed list). This way, you'd save a lot of add/remove operations on the to-be-processed list/vector which might be quite time-consuming.That's all for now. Hope that helps.   ;  Hey thanks for your tipps, they reall help me to figgure things out.@ Lord_Evil:I think the idea about the Entities rather being a label/id is great in theory, but I don't really see the big benefits in practice right now, because as you said it makes the component to component communication rather difficult, could you tell me what the benefits about scrapping entities as a class are in your opinion?Thanks guys![Edited by - mokaschitta on May 16, 2010 3:54:39 PM];  Well, inter-component communication would need to retrieve the components and cache the pointers/indices, so that would not be the problem.A benefit of scapping the entity would be the easier add/remove operations of components, i.e. "entities" could be changed at runtime (add another visual component, add a relationship component, remove a trigger etc.). Since the entity class' base use would be to locate other components that belong to that entity and such lookups should not happen that often it should be possible to scrap it.However, you're right with your doubts and I have yet to check if that approach is really practical. Unfortunately I don't have much time to do that right now, so it could take a while.   ;  Hi,I thought about this approach a little more and I am kind of confused right now, so I'd like to play things through with a little example. Let's say I have a very simple car Entity which should have two behaviours like setSpeed() and crashed() or something. As far as I understand in this approach, I would implement that behaviour in a specific subsystem right? So I would basically outsource the behaviour usually put in a component to a subsystem? What if the subsystem has multiple functions (like setSpeed() and crashed()), how does it know what to do with the entities from the "toBeProcessedList". Would I maybe have a toBeProcessedList for each behaviour possible, or send a state/message with each entity to the toBeProcessedList, to be able to know what to do with it? Or am I misunderstanding the whole concept?   ;  You wouldn't have a subsystem or to-be-processed list for each behavior but maybe for different entity "types" (cars, actors, etc.) or just an AI or Game subsystem.IMHO setSpeed() and crashed() are not behaviors themselves but parts of something like a vehicle behavior. A message would also just be data that is processed, i.e. the entity/component is put into the to-be-processed list and the subsystem starts processing with reading/parsing the message.In a game you'd have to make the distinction between engine code and game code. For the engine, game code is also just data that needs to be processed. This game code might be provided via scripts or through fixed functionality that is driven by some data, but for the engine (where the subsystems are hosted) it is irrelevant.Such code might have a similiar function as shaders/states have for rendering: you wouldn't have a graphics subsystem for each kind of shader, but a single system that binds the shaders, sets uniform and varying attributes and issues an execute command to the driver. For the graphics system shaders and states are just data that describes how it should execute and it would process each entity in the to-be-processed list according to the graphics data associated with that entity.It's quite late, so I hope that makes it clearer now. If not, please don't hesitate to ask.   ;  Yes, I think I understand it now, thanks!   