xna - When to use GameComponents?

I know what it is and I'm using it as a frame counter for example. But when should I use it?

Does it make sense to say "I make all the input handling happen in a gamecomponent"? Is it flexible enough to add and remove fast in runtime? I see I can set the update order and draw order, but I guess to keep track of it an enum should be best like "GamePadInput = 0" or "MessageBox = 100".

Or should I just design simple, for example when I want to determinate if a messagebox is open checking "if (MessageBox.Active)" and then manually updating/drawing?

I'm a bit confused and can't decide what to do. I don't want to start designing the game and see later "oops". Maybe you can help me out :)

Answer

I've got a big, somewhat controversial discussion over here about why Game Components are "bad".

The most annoying thing about GameComponent, for me, is that it looks really important. It looks like a first-class part of the XNA API - like Vector3 or SoundEffect - but they're actually not (everything in the Game assembly is technically optional).

So many an inexperienced developer (and a few intermediate ones who, frankly, have no taste) will come along thinking that implementing things with GameComponent is The Way to architect a game. It's not. And often they end up tying themselves up in knots to try and squash their code into a GameComponent shaped box.

So, to answer your question, when should you use GameComponent?

The "correct", "I am an experienced software engineer and know what I'm doing" answer is that you should probably only use GameComponent for its intended purpose: creating extremely loosely-coupled drag-and-drop style components to share between different games and different developers.

GameComponent (and its friend DrawableGameComponent) were designed to this exact thing. No more and no less.

Now, that being said, you can "fudge" this a little. If you wanted to explore the architectural possibilities, you could (as Maik in comments suggests) use GameComponent as some generic list for retaining game objects. However you will probably very quickly find that you have trouble with, for example, trying to get objects into your Draw or Update methods.

It is at this point that you should let go of GameComponent and take the few minutes to throw together your own actor/game-object/component base class and make a list of those. It really is a handful of lines of code.

(For some components you could just remove the base class completely and call Draw and Update directly. In fact, for some components - especially unique ones that have a fixed position in the draw/update order - this is often superior, as it removes a layer of indirection from your code.)

See also this answer on architecture.