Bit of an intro first...

Well, hello everyone. This is my first post in my shiny new (and first ever) Blog spot. I have to admit to being a bit nervous, but I wanted to put something back into a site that has really helped me out so I hope that at least 1 or 2 of my XNA projects, observations or issues from the last few years of dabbling might be of use to others. I thought I'd kick off with a bit of a summary of the concepts of a Components & Services in XNA to improve the structure, re-usability and maintainability of project. I know that this is likely to be a basic topic for many of you, but it made such an impact on my productivity when I understood & embraced the concepts, that I would like to give anyone new to XNA the heads up right from the outset.

Now (hopefully) the more interesting bit...

After previous dabblings in directx, I was pretty pleased to discover that my very first project under XNA came with the key Update & Draw functions already created. What's more they were magically called for me, without all of the win32 shinanigans previously required! I'm guessing that, like me, many of you immediately went on to pack these two functions with 99% of your first game code. I kept this up for about my first 6 projects before I realised that this wasn't... er, very good practice, to say the least!

Firstly, at the beginning of most game projects you need a lot of similar 'boilerplate' code and I was getting a bit fed up at how difficult (and foolish) it was to cut & paste all the required bits of 'wiring up' for each class or piece of functionality from all over the main game object's methods & properties. Secondly, managing the game object's update & draw functions became rapidly & increasingly complicated as I added more functionality to my basic games. Then I came across this Game Component Demo from Mitch Walker, although it is now a bit dated, it is still conveys the potential of components to resolve these issues and I haven't looked back since!

The idea behind Game Components is to provide a framework for keeping your reusable code in a nicely encapsulated form. The dependencies between these classes can also be managed & de-coupled from one another (using Services, which I will discuss in a separate post) so that they can be removed, altered or replaced in isolation - or even dropped into another completely new projects quickly & easily.

So how do you begin to use them?

Well the first clue can be seen if you examine the properties of your default Game class. You can see that there is a Components property. This is a Collection of Game Components and indicates that the location where instances of your components will ultimately end up.

Creating a Game Component

OK so lets start with the simple task of creating an class for an object that we wish to render. Typically we would need to create a class with a Draw & Update method and we would call these methods directly from the equivalent functions in our game class. By creating the class as a Game Component and then adding it to the Game object's Game Component Collection, however, we can allow the game to manage this process for us.

To create a new class based on a Game Component you can use the class template provided with the framework

• Right Click your project
• Select Add->New Item...
  

In my installation the GameComponent template is under the XNA GameStudio3.0 category, in your setup (and according to the MSDN docs) it may be under your 3.1 category instead.

• Select the Game Component, give it a sensible name and click Add

You should now find that your new Game Component class has been added to your project. If you take a look at the code you will see 2 overrides:

public override void Initialize()
{
    // TODO: Add your initialization code here

    base.Initialize();
}

and

public override void Update(GameTime gameTime)
{
    // TODO: Add your update code here

    base.Update(gameTime);
}

You should also notice that the constructor requires a Game object:

public class GameComponent1 : Microsoft.Xna.Framework.GameComponent
{
    public GameComponent1(Game game)
        : base(game)
    {
        // TODO: Construct any child components here
    }

This will potentially allow your component access to the properties & methods of its containing game class, but in my next post we’ll see how these are best mediated wherever possible using the Game Services design pattern.

Wiring up your component

To add your new component to your game, modify the Game object’s constructor thus:

public Game1()
{
    graphics = new GraphicsDeviceManager(this);
    Content.RootDirectory = "Content";

    Components.Add(new GameComponent1(this));
}

Now put a break point on in the Update function of your component and run the game. You should hit the break point pretty much straight away. If you look at the stack you will see that this is being called automatically as part of the game’s own Update function, the equivalent functions from each of the components in the Components collection are called automatically in this way so you will see that also the case for Initialize function too. Already you can hopefully see that structurally you are already in a position to keep the code relating to this object entirely out of your main game class’s methods – a big improvement on my earliest game projects ;)

Creating a DrawableGameComponent

You can now also manually modify the inheritance of your game component object so that it is now inherits from the DrawableGameComponent class. This is a subclass of the base GameComponent with additional methods supported by the component framework. For some reason, there is no template provided for this class, but it is pretty handy:

With your object now inheriting  from a DrawableGameComponent you can override the Draw method and pop a break point on it. Now when you run your project you will find that the Update & Draw methods of your component are now both being automatically called by the game object, so long as this object is in its Components collection.

In my next posting I’ll take a bit of a look at how to get your components ‘talking’ to one another in a way that still maintains a good degree of decoupling using Game Services. I hope this is interesting to those of you getting started on your own libraries of toolsets.