Проект XNA - кто отвечает за рисование?

Question

Я просто играю с XNA, и у меня есть несколько разных моделей, которые мне нужно нарисовать в каждом кадре. на данный момент объект Game содержит ссылки на все мои модели и рисует их одну за другой. У каждого свой собственный способ рисования - у одной есть две отдельные текстуры, другая может быть отражена на другой стороне и т. Д.

Мне было интересно, допустимо ли просто добавить

public void Draw(SpriteBatch spriteBatch)

метод для всех моих моделей (от BaseModel, конечно), и каждый класс должен отвечать за рисование, или, может быть, я должен позволить классам устанавливать свои данные в соответствии с событиями (KeyboardState) в методе Update и сохраните всю графическую логику в классе Game.

Есть ли предпочтительный способ сделать это?

Answer 1

Как правило, у меня есть базовый класс, который содержит BaseModel, данные текстуры, данные поворота и масштаба и т. Д. Для каждого типа актера в игре я создаю производный класс. Базовый класс предоставляет метод Draw, который по умолчанию рисует модель с данными текстуры, вращения и масштаба, указанными в классе. Производные классы могут переопределить его, чтобы нарисовать актера так, как им нравится.

Затем у меня есть DrawableGameComponent, который действует как мой граф сцены. Он содержит список всех активных объектов актера. В методах Draw и Update компонента я перебираю список актеров и вызываю их методы Draw и Update.

Answer 2

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

Пример ... скажем, у вас есть несколько кораблей. Некоторые летят быстро, некоторые стреляют ракетами, у некоторых вокруг него вращается спутник, который также стреляет. Ваш класс "Entity" может иметь следующие свойства

• Модель VisualRepresentation
• Положение матрицы
• Entity [] AttachedEntities

Ваш рендерер может затем перебрать ваш общий "List<Entity>", и

1. Нарисуйте визуальное представление (т.е. модель) объекта, используя позицию
2. Зацикливайтесь на AttachedEntities и рисуйте их (рекурсивно).

Это, очевидно, упрощенный пример ... но в этом случае логика рисования полностью содержится в коде рендеринга, и ей нужно только заниматься как можно меньшим количеством информации. Хотя класс корабля может фокусироваться на самой игровой логике (т. Е. На какой скорости я летаю, какое оружие я использую, сколько энергии у меня на щитах и ​​т. Д.).

Что касается того, какой из них предпочтителен, то ответ на самом деле лежит в пределах требований вашего проекта и того, что вам удобно. Не пытайтесь создать игровой движок перед созданием игры ... просто делайте все, что нужно, чтобы сделать вашу игру, и тогда возможно вы можете извлечь компоненты, которые работали после вас Корабль игры: -P