What are the cons of using DrawableGameComponent for every instance of a game object?

Question

I've read in many places that DrawableGameComponents should be saved for things like "levels" or some kind of managers instead of using them, for example, for characters or tiles (Like this guy says here). But I don't understand why this is so. I read this post and it made a lot of sense to me, but these are the minority.

I usually wouldn't pay too much attention to things like these, but in this case I would like to know why the apparent majority believes this is not the way to go. Maybe I'm missing something.

Answer 1

"Game Components" were a very early part of the XNA 1.0 design. They were supposed to work like controls for WinForms. The idea was that you would be able to drag-and-drop them into your game using a GUI (kind of like the bit for adding non-visual controls, like timers, etc) and set properties on them.

So you could have components like maybe a Camera or a... FPS counter?... or...?

You see? Unfortunately this idea doesn't really work for real-world games. The kind of components you want for a game aren't really reusable. You might have a "player" component, but it will be very different to every other's game's "player" component.

I imagine it was for this reason, and for a simple lack of time, that the GUI was pulled before XNA 1.0.

But the API is still usable... Here's why you shouldn't use it:

Basically it comes down to what is easiest to write and read and debug and maintain as a game developer. Doing something like this in your loading code:

player.DrawOrder = 100;
enemy.DrawOrder = 200;

Is much less clear than simply doing this:

virtual void Draw(GameTime gameTime)
{
    player.Draw();
    enemy.Draw();
}

Especially when, in a real-world game, you might end up with something like this:

GraphicsDevice.Viewport = cameraOne.Viewport;
player.Draw(cameraOne, spriteBatch);
enemy.Draw(cameraOne, spriteBatch);

GraphicsDevice.Viewport = cameraTwo.Viewport;
player.Draw(cameraTwo, spriteBatch);
enemy.Draw(cameraTwo, spriteBatch);

(Admittedly you could share the camera and spriteBatch using the similar Services architecture. But that is also a bad idea for much the same reason.)

This architecture - or lack thereof - is so much more light weight and flexible!

I can easily change the draw order or add multiple viewports or add a render target effect, just by changing a few lines. To do it in the other system requires me to think about what all those components - spread across multiple files - are doing, and in what order.

It's sort of like the difference between declarative vs imperative programming. It turns out that, for game development, imperative programming is far more preferable.

Answer 2

Hmmm. Got challenge this one for the sake of a bit of balance here I'm afraid.

There seem to be 5 charges in Andrew's reply, so I'll try and deal with each in turn:

1) Components are an out-of-date and abandoned design.

The idea of components design pattern existed long before XNA - in essence it is simply a decision to make objects, rather than the over-arching game object, the home of their own Update and Draw behaviour. For objects in its component collection, the game will call these methods (and a couple of others) automatically at the appropriate time - crucially the game object does not itself have to 'know' any of this code. If you wish to re-use your game classes in different games (and thus different Game objects), this de-coupling of objects is still fundementally a good idea. A quick look at the latest (professionally produced) demos of XNA4.0 from the AppHub confirms my impression that Microsoft are still (quite rightly in my view) firmly behind this one.

2) Andrew can't think of more than 2 re-usable game classes.

I can. In fact I can think of loads! I've just checked my current shared lib, and it comprises more than 80 re-usable components and services. To give you a flavour, you could have:

• Game State/Screen Managers
• ParticleEmitters
• Drawable primitives
• AI controllers
• Input controllers
• Animation controllers
• Billboards
• Physics & Collision Managers
• Cameras

Any particular game idea will need at least 5-10 things from this set - guaranteed - and they can be fully functional in a completely new game with one line of code.

3) Controlling draw order by the order of explicit draw calls is preferrable to using the component's DrawOrder property.

Well, I basically agree with Andrew on this one. BUT, if you leave all you component's DrawOrder properties as default, you can still explicitly control their draw order by the order in which you add them to the collection. This is really identical in 'visibility' terms to explicit ordering of their manual draw calls.

4) Calling a load of object's Draw methods yourself is more 'lightweight' than having them called by an existing framework method.

Why? Plus, in all but the most trivial of projects your Update logic and Draw code will totally overshadow your method calling in terms of performance hit in any case.

5) Placing your code in one file is preferrable, when debugging, than having it in the individual object's file.

Well, firstly, when I'm debugging in Visual Studio the location of a breakpoint in terms of files on disk is almost invisible these days - the IDE deals with the location without any drama. But also consider for a moment that you have a problem with your Skybox drawing. Is going to the Skybox's Draw method really more onerous than locating the skybox drawing code in the (presumably very lengthy) master draw method in the Game object? Nope, not really - in fact I would argue that it is quite the opposite.

So, in summary - please take a long hard look at Andrew's arguments here. I don't believe they actually give substantive grounds to write entangled game code. The upsides of the decoupled component pattern (used judiciously) are massive.

Answer 3

I disagree a bit with Andrew, but I also think there is a time and place for everything. I would not use a Drawable(GameComponent) for something as simple as a Sprite or Enemy. However, I would use it for a SpriteManager or EnemyManager.

Going back to what Andrew said about draw and update order, I think Sprite.DrawOrder would be very confusing for many sprites. Moreover, its relatively easy to set up a DrawOrder and UpdateOrder for a small (or reasonable) amount of Managers that are (Drawable)GameComponents.

I think that Microsoft would have done away with them if they really where that rigid and nobody used them. But they haven't because they work perfectly fine, if the role is right. I myself use them to develop Game.Services that are updated in the background.

Answer 4

I was thinking about this as well, and it occurred to me: For instance, to steal the example in your link, in an RTS game you could make every unit a game component instance. Okay.

But you could also make a UnitManager component, which keeps a list of units, draws and updates them as necessary. I guess the reason you want to make your units into game components in the first place is to compartmentalize code, so would this solution adequately achieve that goal?