我最近跳进了XNA池，并且正在学习C＃中框架的所有细节。我在研究中注意到的一件事是，似乎没有广泛接受的“正确”方式来实现GameComponents。
在阅读this thread（以及其他）之后，我发现了游戏开发者的广泛偏好。我见过一些倡导者从不使用GameComponents（或只是少量使用），而其他人声称将它们用于所有，直到玩家/敌方单位，导弹等等。然后有一些采取更温和的方法，并为中高级实体保留GameComponent架构，如屏幕，渲染器，场景等，反过来包含并驱动更细粒度的游戏单元。
在一天结束时，由游戏开发人员决定如何最好地实施框架。由于StackOverflow充满了精明的开发人员，他们已经忘记了我所知道的更多，我希望能够在我继续沿着这条路径继续使用框架之前了解共识是什么。
有人关心他们的想法吗？提前谢谢！
答案 0 :(得分：2)
我对XNA也很陌生，所以请耐心等待这个答案。
我认为它可以归结为一种风格偏好。我不确定使用GameComponent与更多手动方式之间的性能特征，但我知道，对于我个人来说，我很快就试图利用GameComponent而感到沮丧，因为它并没有真正融入我的思维或编程风格。从内心来说，我是从OOP，程序，功能和其他编程范例中汲取的混合物。 GameComponent似乎正在使用严格的OOP方法。
但我要说的是，将一切作为一个GameComponent，甚至是一般的类，在性能方面都会成为问题。最大可读性和可维护性的问题似乎在游戏开发世界中占据优势，有时你真的需要从代码中挤出优化。例如，有时最好将你的一个游戏对象变成一个结构（值类型），这样你就可以节省一些内存并阻止讨厌的垃圾收集器使你的游戏延迟（正如我在{{3}中学到的那样） }）。