Настройки реализации XNA GameComponent ...?

Question

Я недавно подключился к пулу XNA и изучаю все входы и выходы фреймворка в C #. В своих исследованиях я обратил внимание на то, что, похоже, не существует общепринятого «правильного» способа реализации GameComponents.

После прочтения этой темы (среди прочих) я обнаружил широкий спектр предпочтений среди разработчиков игр. Я видел, как некоторые адвокаты никогда не использовали GameComponents вообще (или только экономно), в то время как другие утверждают, что используют их для всего , вплоть до юнитов игрока / противника, ракет и т. Д. Тогда есть некоторые, которые выберите более умеренный подход и зарезервируйте архитектуру GameComponent для объектов среднего и высокого уровня, таких как экраны, средства визуализации, сцены и т. д., которые, в свою очередь, содержат и управляют более детализированными игровыми модулями.

В конце концов, разработчик игры должен определить, как лучше всего реализовать фреймворк. Так как StackOverflow заполнен опытными разработчиками, которые забыли больше, чем я когда-либо знаю, я хотел бы получить представление о консенсусе, прежде чем я продолжу двигаться дальше по этому пути, используя свое собственное использование фреймворка.

Кто-нибудь хочет присоединиться к своим мыслям? Заранее спасибо!

Answer 1

Я довольно новичок в XNA, поэтому примите этот ответ с недоверием.

Я думаю, что это может сводиться к предпочтениям стиля. Я не уверен в характеристиках производительности между использованием GameComponent и более ручными способами, но я знаю, что лично я быстро разочаровался, пытаясь использовать GameComponent, так как это не совпало с моим стилем мышления или программирования. В глубине души я представляю собой смесь вещей, которые я взял из ООП, процедурных, функциональных и других парадигм программирования. GameComponent, похоже, использует строгий ООП подход.

Но я скажу, что создание всего GameComponent или даже класса в целом может стать проблематичным в том, что касается производительности. Вопросы максимальной читабельности и удобства сопровождения, кажется, находятся на острие в мире разработки игр, где иногда вам действительно нужно выжать оптимизацию из вашего кода. Например, иногда лучше превратить один из ваших игровых объектов в структуру (тип-значение), чтобы вы могли сэкономить память и мешать сборщику мусора мешать игре (как я изучал в this вопрос, который я задал ).