Sign in to follow this  
Kriuq

Component-based engine questions

Recommended Posts

Hey, I've been thinking about component-based architecture for game engines recently, and I've been stuck on a couple issues: 1. Possibly global classes (physics, rendering) that need to keep track of/get information about many entities. Should I use global classes and just update() them in the main loop? Or should I make a component that handles global physics, or a component that handles rendering, and then just put one on an entity and let it get updated automatically? 2. Communication between entities. Do I need to have dependencies for entity components? For example, a component that stores information and does calculations related to rendering has to have access to the ent's position (which currently I'm just storing in a basic physics component) My ideas for this are: - Have dependencies, could be annoying for referencing variables self.entity.physics_component.x - Use entity-wide messaging/events to communicate this stuff, could get really slow and bulky, but if you don't have the physics component then it won't error. 3. Where do I implement basic logic? For example, the player object will have all sorts of logic for when to change animations - should this just be implemented as a component I use only once? By the way, I'm doing this in 2D, and with python - if that matters. Thanks.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kriuq
1. Possibly global classes (physics, rendering) that need to keep track of/get information about many entities. Should I use global classes and just update() them in the main loop? Or should I make a component that handles global physics, or a component that handles rendering, and then just put one on an entity and let it get updated automatically?

2. Communication between entities. Do I need to have dependencies for entity components? For example, a component that stores information and does calculations related to rendering has to have access to the ent's position (which currently I'm just storing in a basic physics component)

My ideas for this are:
- Have dependencies, could be annoying for referencing variables self.entity.physics_component.x

- Use entity-wide messaging/events to communicate this stuff, could get really slow and bulky, but if you don't have the physics component then it won't error.

3. Where do I implement basic logic? For example, the player object will have all sorts of logic for when to change animations - should this just be implemented as a component I use only once?

By the way, I'm doing this in 2D, and with python - if that matters.
Thanks.


1) The components keep track of each entity's data. Remember that. The manager (whether you make it global or not) is only responsible for updating it. There is no one "right" way to do this, but let me briefly tell you what I'm doing for my current component-based project and that might give you some ideas. In my current project I have a Physics manager which updates all the physics components, a Graphics manager which updates all the graphics components, etc. In other words, each manager contains a list of pointers to their respective components (the entities themselves actually store the components). In the main loop, I update each manager, which in turn updates each component.

For example, a graphics component might contain data like model ID, texture ID, color, visibility, etc - but it just contains the data and nothing else. The graphics manager then looks at each graphics component and renders it. But how does it know where to put it on the screen? Well, the graphics manager is able to access the entity's physics component through the graphics component because each component contains a pointer to the entity in which it is apart of. (But remember, this is just one way of doing it). The point is that the graphics manager doesn't know or care if it's rendering a car, a house, or a tree. All it knows how to do is take the data that's supplied in the graphics component and render that to the screen. The same idea is applied to all your components/managers.

2) This is exactly the question I had to ask myself - Graphics needs to know the position of the entity, but position is stored in Physics. I decided in the end not to use a message-based system, and instead reference the component's data like you said. Except instead of:


self.entity.physics_component.x


Mine is slightly more sophisticated:


CPhysics * phys_comp = entity->GetComponent<CPhysics>();

if (phys_comp)
....


Every time I query a component from an entity, I have to check for null - one of the consequences of my architecture design, but that's just the way it is and I can live with that.

3) You could make an AI component. But each entity is probably going to have different types of AI. So one possible solution is to make a base AI component and have other types of AI components derive from that. Another solution is to simply put it in the Player class itself and not bother making an AI component, knowing you could always refactor later. Of course, if all you have is a single "Entity" class and nothing derives from that, then you're pretty much forced into making an AI component one way or another.

I'm sorry I couldn't give you any more insight then that, but I'm sure others will be able to. Unfortunately there's no hard and fast answer for most of your questions. Regardless, a good idea to keep in mind is that you want to strike a balance between flexibility and simplicity. It's really easy for some people to fall into the trap of making their architecture more complex than it needs to be. I recommend searching these forums too, because component-based architecture has been brought up countless times.

[Edited by - fd9_ on October 13, 2007 2:47:49 AM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this