component-based game object management framework

Raveler 101 Jan 19, 2009 at 23:26

Hello guys,

I have a fairly simple question for you guys, but I have not managed to find the answer on the internet anywhere. Has anyone if you succesfully implemented and used a component-based framework in a of your reasonable sized game project? Please bear with me, I’ll explain myself.

I am talking about a component-based system as described by some of the following links:\~scottb/gdc/game-objects_files/frame.htm

When you read the pages, it all makes perfect sense. It’s also not so difficult to implement a good framework for creating objects, creating components, attaching them to objects and have them communicate with each other. I have opted, as have most people who use this approach it seems, for a message-system to communicate between components. So one component sends (or broadcasts) a message, and other components who are listening pick up the message and respond to it.

So far so good… everything still seems to make sense.

But when I start to actually USE this system in a game, I get completely stuck. I completely and utterly fail to convert my seasoned inheritance-based thinking to the new paradigm. To make this more concrete, here are some examples I am struggling with:

  1. In my game, I am using a quad tree to manage game objects, and to increase performance in expensive operations such as drawing and collision detection. Implementing this in an inheritance system is very straight forward, but I can’t find a way to translate this to a component-based system for the life of me.

  2. Performing actions on objects in a particular order. For example, I want to draw sprites on screen starting from the one with the lowest z-value up to the sprite with the highest z-value, so that sprites “closer” to the player are drawn on top of previous ones. How to do this neatly and efficiently in a message-based, component-based system, I don’t know.

I’m sure that anyone who has ever used a component-based system with success must have tackled these problems, since both are pretty much essential tasks in every 2D game. So if you can give me some insight in how to solve these problems, and how to actually USE such a component-based framework in general, it would be greatly appreciated.


5 Replies

Please log in or register to post a reply.

JarkkoL 102 Jan 20, 2009 at 09:28

I use component based design in a game engine I’m working on, but it’s not a “reasonable sized game project” though and I have been working only on the rendering part so far, so there hasn’t been any need to communicate between components yet. However, there is a graphics component in a world entity, which is accessed by a renderer to perform needed operations in order to visualize the entity. Each component uses inheritance though, so I don’t quite see what’s the problem you are facing with your design.

alphadog 101 Jan 20, 2009 at 16:50

I’m not quite sure how to go about answering, in part because the breath of the question is so wide. Also, any answer highly depends on knowing/seeing your current architecture, and how you’ve applied component-based design.

That being said, I suspect you may either be using the word “component” in a different way that I do (as I think the Cowboy Programmer does), or you may have “over-componentized” your design. I say that only because it is the most typical source of error, and may not apply to you and I am wayyyy off… ;)

laweya 101 Jan 20, 2009 at 18:20

Hi Raveler,

First, I would suggest that you have a look at the nebula 2 engine and in particular, its Mangalore framework. Apart from being a very well designed framework (IMHO), it implements a component based system.

For 1 above, as JarkkoL has mentioned, you will need to provide more information for someone to provide more help.

To answer 2 above, I think you would be better off doing your drawing routines using inheritance and leave the component based bits for higher level parts of the program/game. I believe component based systems are best suited where you need to re-use code to create new components that you might not have envisioned while designing the system.

e.g. talks about implementing it in game entity management.

Assuming you have a Graphics component that handles all primitive rendering and a Physics component that handles physics simulation, instead of creating a base entity class and sub-classing it to create a model class for rendering, then sub-classing that to create a “physics-model” class and having to write and maintain code for each subclass, simply create an empty Entity class that could have just the Graphics component attached to make it only graphical or just the physics component to make it just physic(al) or both to make it both graphical and physic(al).

In the case of Mangalore (nebula 2), the entity is simply a message dispatcher that sends messages to its attached components. After the physics simulation, the physics component transmits an “UpdateTransform” message to its owner/entity which in turn broadcasts to it to its attached components. Components that don’t understand the message ignore it while the Graphics component should ideally modify its transform matrix.

kariem2k 101 Jan 21, 2009 at 08:54

Mangalore is very good example of component based design, allso you can check the new under development framework Nebula 3 which is in its early stages of development but it is better designed and it is based on the concepts of mangalore.

Also you can take a look at yake it is also has that layer, or delta3d which has some new concepts in that field also oge.

alphadog 101 Jan 21, 2009 at 14:27

Yeah, what kariemk2k said. ;)

Careful with TND2/Mangalore (a.k.a. Nebula 2). I’ve heard it said that it is a bit messy. In fact, Mangalore is a “solution” (fork?) for FPSes mainly, that works around that messy parts of TND2.

TND3 seems to be moving towards fixing much of TND2, though, and may be a better example of component-based design ideas. If you are just looking for ideas on architecture, skip Mangalore and TND2 and go to TND3.

See Floh’s blog for more details…