XNA GameComponent Implementation Preferences...?

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!

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

Thanks for the response! I've heard that using the Game.Components collection causes low overhead, but it sounds like you contend otherwise. Do you think that creating one's own entity hierarchy/management system offers greater performance potential?

Syndog 2010-02-25 23:15:32

I'm sorry, I really don't know. You certainly get more control, so maybe you can squeeze more performance out. But then again, MS probably knows where they're doing and squeezed performance out of GameComponent to begin with :) But for certain objects, particularly if you plan to have alot of them on screen (like bullets), they're better left as structs for performance reasons

Bob 2010-02-25 23:21:27

GameComponents is going to be implemented as a list internally, can't get much more efficient than that! As for structs, I'm not sure that's a great idea, passing a struct about in C# will involve lots of copying values. The garbage collector is only slow on the xbox, on PC you can pretty much just forget about it.

Martin 2010-02-25 23:46:05

Nb. Instead of structs, keeping a resource pool is often a better way of doing things, so you reuse old bullet instances.

Martin 2010-02-25 23:46:45

@Martin: Might be more beneficial if you commented on the bullet issue in Bob's thread. Just sayin'... ;)

Syndog 2010-02-25 23:56:57

ansaurus

tags:

views:

answers:

XNA GameComponent Implementation Preferences...?

related questions