Skip to main content
broken link fixed, cf. https://meta.stackoverflow.com/a/406565/4751173
Source Link

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see linksee link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.

Personally, I don't even use game components at all. I prefer having precise control over the updating and drawing of my classes, and if I need a reference to Game I can pass it on the constructor just as well without making the class a GameComponent. Don't let that discourage you from using them though, it's just a matter of personal preference, but just make sure you use them for the right task.

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.

Personally, I don't even use game components at all. I prefer having precise control over the updating and drawing of my classes, and if I need a reference to Game I can pass it on the constructor just as well without making the class a GameComponent. Don't let that discourage you from using them though, it's just a matter of personal preference, but just make sure you use them for the right task.

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.

Personally, I don't even use game components at all. I prefer having precise control over the updating and drawing of my classes, and if I need a reference to Game I can pass it on the constructor just as well without making the class a GameComponent. Don't let that discourage you from using them though, it's just a matter of personal preference, but just make sure you use them for the right task.

added 259 characters in body
Source Link
David Gouveia
  • 24.9k
  • 5
  • 87
  • 125

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.

Personally, I don't even use game components at all. I prefer having precise control over the updating and drawing of my classes, and if I need a reference to Game I can pass it on the constructor just as well without making the class a GameComponent. Don't let that discourage you from using them though, it's just a matter of personal preference, but just make sure you use them for the right task.

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.

Personally, I don't even use game components at all. I prefer having precise control over the updating and drawing of my classes, and if I need a reference to Game I can pass it on the constructor just as well without making the class a GameComponent. Don't let that discourage you from using them though, it's just a matter of personal preference, but just make sure you use them for the right task.

Source Link
David Gouveia
  • 24.9k
  • 5
  • 87
  • 125

Was it even a good thing to do, making the Class a GameComponent?

No. You should only consider using GameComponents for higher level concepts that sit directly on top of your Game class and will only require one instance to exist at any time.

Good examples are classes with Manager in their names such as a ScreenManager, InputManager or AudioManager, or classes that are built to be plug and play such as a FramerateCounter (see link) that you can easily reuse in any other project just by dropping it in.

So if for instance you created a scene graph class to store and manage the rendering and updating of your game world and all of its objects, you might consider making it a DrawableGameComponent. On the other hand, using it for each individual game object is not recommended at all.