Разделение игры и логики рендеринга
Что лучший способ состоит в том, чтобы разделить код рендеринга от на самом деле игровой код механизма/логики? И это - даже хорошая идея разделить их?
Давайте предположим, что у нас есть игровой объект, названный Рыцарем. Рыцарь должен быть представлен на экране для пользователя для наблюдения. Нас теперь оставляют с двумя вариантами. Любой мы даем Рыцарю a Render/Draw метод, который мы можем назвать, или мы создаем класс рендерера, который заботится о рендеринге всех рыцарей.
В сценарии, где эти два разделяются Рыцарь, Рыцарь должен все еще содержать всю информацию, должен был представить его, или это должно быть разделено также?
В последнем проекте, который мы создали, мы решили позволить всей информации, запрошенной для рендеринга объекта быть сохраненными в самом объекте, но у нас был отдельный компонент, чтобы на самом деле считать ту информацию и представить объекты. Объект содержал бы информацию, такую как размер, вращение, масштаб, и какая анимация в настоящее время играла и на основе этого, объект рендерера составит экран.
Платформы, такие как XNA, кажется, думают, присоединяясь к объекту, и рендеринг является хорошей идеей, но мы боимся быть связанными до определенной платформы рендеринга, тогда как создание отдельного компонента рендеринга дает нам больше свободы изменить платформу в любой момент времени.
2 ответа
Я бы постарался сделать ваши объекты как можно более общими и по возможности избегать кодирования фактов игрового процесса в вашем коде.
Например. у вас есть класс Entity, Object или Actor, и у этого класса есть указатель на принятие решения (его AI) и указатель на его графическое представление.
Принятие решения обязательно связано с фактами игрового процесса; действительно, это часть игрового процесса. Так что здесь вы можете назвать лицо, принимающее решения, «KnightAi» или что-то в этом роде.
С другой стороны, графическое представление - это всего лишь часть графики. Он будет нарисован так же, как и любой другой объект. У вас есть модель или несколько растровых изображений и некоторые анимации, или нет ... Это можно было бы просто назвать чем-то вроде «Модель» и загрузить информацию, которую он сказал для загрузки, определяет, как объект выглядит для игрока. Когда дело доходит до рендеринга вашего рыцаря, вашей лошади или замка, вы, вероятно, обнаружите, что все они делают одно и то же, только с разными данными. Типы данных, которые у них есть, даже все одинаковы, различается только их содержимое.
Допустим, все ваши сущности были представлены в виде кругов. Вы бы просто указали на объект CircleRenderer, который имеет размер, необходимый для их рисования. Вы бы не стали создавать разные классы рендерера для каждого разного размера (или цвета, или чего-то еще) круга, который вам нужен!
Я бы создал отдельный класс KnightRenderer . Преимущества:
- Четкое разделение игровой логики и рендеринга.
Рыцарьмог даже работать на игровом сервере и вообще ничего не знать о рендеринге. - Меньшие, более простые классы, связанные с одной-единственной функциональностью.
Все, что KnightRenderer должен знать о Knight (должность, статус), должно быть открыто для чтения в Knight .
Свойства, относящиеся к рендерингу, должны входить в класс KnightRenderer . Например, вы хотите, чтобы рыцарь вспыхивал при ударе, поэтому вам нужно сохранить счетчик или значение времени.