XNA GameComponent Implementation Preferences...?

Question

I've recently jumped into the XNA pool, and am learning all the ins and outs of the framework in C#. One thing I've noticed in my research is that there seems to be no widely accepted "proper" way to implement GameComponents.

After reading this thread (among others), I've discovered a broad spectrum of preferences among game developers. I've seen some advocate never using GameComponents at all (or only sparingly), while others claim to use them for everything, right down to the player/enemy units, missiles, etc. Then there are some that take a more moderate approach, and reserve the GameComponent architecture for mid- to high-level entities such as screens, renderers, scenes, etc. that in turn contain and drive their more granular game units.

At the end of the day, it's up to the game developer to determine how best to implement the framework. Since StackOverflow is packed with savvy developers who have forgotten more than I'll ever know, I'd like to get a feel for what the consensus is here before I continue further down this path with my own use of the framework.

Anyone care to chime in with their thoughts? Thanks in advance!

Answer 1

I'm pretty new to XNA as well so take this answer with a grain of salt.

I think it can boil down to a style preference. I'm not sure the performance characteristics between using GameComponent versus more manual ways, but I know that for me, personally, I quickly grew frustrated trying to utilize GameComponent as it didn't really mesh with my style of thinking or programming. At heart I'm a mix of things I've picked up from OOP, procedural, functional, and other programming paradigms. GameComponent seems to be utilizing a strict OOP approach.

But I will say that making everything a GameComponent, or even a class in general, can become problematic where performance is concerned. Questions of maximum readability and maintainability seem to be on a knife's edge in the game development world where sometimes you really do just have to squeeze optimization out of your code. For instance, sometimes it's better to turn one of your game objects into a struct (value-type) so you can save some memory and stop the pesky garbage collector from making your game lag (as I've been learning in this question I asked).