Подтвердить что ты не робот

Разделение логики игры и рендеринга

Каков наилучший способ отделить код рендеринга от собственно игрового движка/логического кода? И разве это даже хорошая идея отделить их?

Предположим, что у нас есть игровой объект Knight. Рыцарь должен отображаться на экране для просмотра пользователем. Теперь у нас есть два варианта. Либо мы даем метод Knight a Render/Draw, который мы можем назвать, либо создаем класс рендеринга, который заботится о рендеринге всех рыцарей.

В сценарии, где эти два разделены, Рыцарь должен, чтобы Рыцарь все еще содержал всю информацию, необходимую для его рендеринга, или же это должно быть разделено?

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

Я постараюсь сделать ваши объекты максимально возможными и избегать кодирования фактов геймплея в ваш код как можно больше.

например. у вас есть класс Entity или Object или Actor, и этот класс имеет указатель на его принятие решений (его AI) и указатель на его графическое представление.

Его принятие решений обязательно связано с фактами геймплея; действительно, это часть фактов геймплея. Итак, это где-то, где вы можете назвать своего лица, принимающего решения "KnightAi" или что-то в этом роде.

С другой стороны, графическое представление представляет собой лишь немного графики. Он будет выглядеть так же, как и любой другой объект. У вас есть модель или некоторые растровые изображения и некоторые анимации или нет... Это можно было бы назвать просто "моделью" и загружать информацию, которую он загружал, чтобы определить, как выглядит объект для игрока. Когда дело доходит до превращения вашего рыцаря в отличие от вашей лошади против замка, вы, скорее всего, обнаружите, что все они делают то же самое, что и с разными данными. Типы данных, которые у них есть, все равно, это просто содержимое, которое отличается.

Скажите, что ваши сущности были представлены в виде кругов. Вы просто хотели бы, чтобы они указывали на CircleRenderer, который взял размер, который они должны быть нарисованы. Вы бы не создали другой класс рендеринга для каждого разного размера (или цвета или любого другого) круга, который вы хотели!

Ответ 2

Я бы создал отдельный класс KnightRenderer. Преимущества:

  • Чистое разделение между логикой игры и рендерингом. Сам Knight может даже запускаться на игровом сервере и вообще ничего не знать о рендеринге.
  • Меньшие, более простые классы, связанные с одной и только одной функциональностью.

Все, что KnightRenderer должно знать о Knight (позиция, статус), должно быть общедоступным для чтения в Knight.

Свойства, специфичные для рендеринга, войдут в класс KnightRenderer. Например, возможно, вы хотите, чтобы рыцарь вспыхнул, когда он ударил, поэтому вам нужно будет сохранить счетчик или значение времени.