Thursday, 27 September 2007

Game Development Tutorial: Component based design or more precisely, the Interface used in CBD

If you´ve read something about XNA, you have probably seen a concept that, though it´s out there for many years now, it´s quite new and specially appropiate for games: Component based programming.

Some people pointed out that I´m talking more about the interface used in the Component Based Design of XNA than the CBD itself, and they are right. Absolutely right.

The important idea I wanted to transmit here is the convenience of using game objects or components that share an interface like the following:

// Object initialization, boot up, etc
void Initialize();

// State update: Put your game logic in here
void Update(double pAppTime, float pElapsedTime);

// Draw method: draw the object if needed
void Render(Device pGraphicsDevice);

The important thing about this methodology is that it keeps a very simple application structure, and every component behaves in the very same way. If you think about it, most of the times you don´t need anything appart from those 3 methods.

In the following posts in this same tag, I´ll include a very simple arkanoid-like game application that follows this mothodology. It´s quite simple, C# and GDI based, but it performs pretty well and shows what I´m talking about.

Cheers!

3 comments:

Anonymous said...

THIS IS NOT COMPONENTS! It is merely a common game object interface so that all objects can go in the same data structure. Components mean that various parts of the game logic are in separate objects that can be linked together dynamically. See:
http://shrt.info/post/2008/09/Improving-your-component-based-framework-Part-1,-evolving-from-the-game-object.aspx

Anonymous said...

Sorry but this is wrong :(

Iñaki Ayucar said...

Components doesn´t need to be DYNAMICALLY linkable to be components. Anyway, yes, you are right.

The post title is not very accurate. Components is much more than just an interface like the one I´m talking about here.

Nevermind...

The biggest point I wanted to focus on, is not components or the interface, but more on the methodology and the change of mind needed to model your game objects following this pattern.

If I had to re-write the post, maybe I´d add two more ideal methods to this interface:

FromXml and ToXml

Maybe I write another post about this issue later.

Sorry for the mess.