Sign up ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
I'm curious as to why, two years later, you've removed the "accepted" mark from my answer? Normally I wouldn't really care - but in this case it causes VeraShackle's infuriating misrepresentation of my answer to bubble to the top :( – Andrew Russell Apr 6 '13 at 9:19
@AndrewRussell I read this thread not long ago (due to some responses and votes) and thought I was not qualified to give an opinion on whether your answer is the correct one or not. As you say, though, I don't think VeraShackle's answer should be the one with the most upvotes, so I'm marking your answer as correct again. – Kensai Apr 7 '13 at 3:38
Thanks :) I'm not completely happy with my answer, two years on - I wish I'd more directly addressed the difference between "managers" and "units". But my overall point is sound: the API is designed for making drag-and-drop style components. So both approaches are ok and can be mixed - when you write components in that context... However, a lot of people advocating "managers" are simply running into the limitations of the API, and suggesting managers as a work-around - missing the fact that you don't have to use the API at all! It fills a need they don't actually have! – Andrew Russell Apr 7 '13 at 5:47

4 Answers 4

up vote 18 down vote accepted

"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)

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.

share|improve this answer
I was under the impression they were for Component-based programming, which is apparently widely used for game programming. – BlueRaja - Danny Pflughoeft May 27 '11 at 21:50
The XNA game component classes aren't really directly applicable to that pattern. That pattern is all about composing objects out of multiple components. The XNA classes are geared to one-component-per-object. If they fit perfectly in your design, then by all means use them. But you should not build your design around them! See also my answer here - look out for where I mention DrawableGameComponent. – Andrew Russell May 28 '11 at 3:03
I agree that the GameComponent/Service architecture isn't all that useful and sounds like Office-like or web application concepts being forced into a game framework. But I'd much prefer to use the player.DrawOrder = 100; method over the imperative one for draw order. I'm finishing a Flixel game right now, which draws objects in the order in which you add them to the scene. The FlxGroup system alleviates some of this, but having some sort of Z-index sorting built in would have been nice. – michael.bartnett Feb 21 '12 at 3:57
@michael.bartnett Note that Flixel is a retained-mode API, while XNA (except, obviously, the game components system) is an immediate-mode API. If you use a retained-mode API, or implement your own, the ability to change draw-order on the fly is definitely important. In fact, the need to change draw-order on the fly is a good reason to make something retained-mode (the example of a windowing system comes to mind). But if you can write something as immediate-mode, if the platform API (like XNA) is built that way, then IMO you should. – Andrew Russell Oct 4 '12 at 11:13

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.

share|improve this answer
I only just noticed this post, and I must issue a strong rebuttal: I have no issue with reusable classes! (Which may have draw and update methods and so on.) I am taking specific issue with using (Drawable)GameComponent to provide your game architecture, due to loss of explicit control over draw/update order (which you agree with in #3) the rigidity of their interfaces (which you don't address). – Andrew Russell Jun 5 '11 at 5:50
Your point #4 takes my use of the word "lightweight" to mean performance, where I actually clearly mean architectural flexibility. Your remaining points #1, #2, and especially #5 seem to erect the absurd straw-man that I think most/all code should be shoved into your main game class! Read my answer here for some of my more detailed thoughts on architecture. – Andrew Russell Jun 5 '11 at 5:50
Finally: if you're going to post a response to my answer, saying that I'm wrong, it would have been courteous to also add a reply to my answer so I would see a notification about it, rather than have to stumble upon it two months later. – Andrew Russell Jun 5 '11 at 5:51
I may have misunderstood, but how does this answer the question? Should I use a GameComponent for my sprites or not? – Superbest Feb 21 '12 at 3:27

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.

share|improve this answer

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?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.