1
\$\begingroup\$

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

\$\endgroup\$
  • 6
    \$\begingroup\$ Dont be afraid to implement a bad design first. Its better than falling into a design paralysis. Good designs are an evolution, implement something, see how it works, improve it if turns out bad. The more experience you get, the smaller the cycles will be, but there is no shortcut for that experience, you only get it from making mistakes, so "oops" is a good thing, just start with your idea. \$\endgroup\$ – Maik Semder May 24 '13 at 7:16
  • \$\begingroup\$ IOW: Good judgement is obtained from the experience of exercising bad judgement. \$\endgroup\$ – Pieter Geerkens May 24 '13 at 7:32
  • \$\begingroup\$ Okay :) I think I'm going with the checking if something is active way. \$\endgroup\$ – Robin Betka May 24 '13 at 7:36
2
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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