Игры: кто отвечает за показ?

Question

Должны ли сущности знать, как рисовать себя? Я использовал этот подход: он прост и работает, но после изучения MVC-шаблонов я чувствую себя неловко по этому поводу. Трудно изменить художественный стиль, когда вся логика дисплея скрыта в модели.

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

Где следует разместить код для рисования таким образом, чтобы он был расширяемым, легко изменяемым, чистым и сухим?

Answer 1

Этот вопрос по-прежнему часто возникает в процессе разработки игр, поскольку различные студии и группы начинают работать с новыми движками.

Короткий ответ заключается в том, что все зависит от сложности ваших игровых объектов.Для простых сущностей это не имеет значения.

Когда вы попадаете в гораздо более сложные сущности, вы должны переосмыслить свой подход.В общем, вы захотите сопротивляться желанию иметь цикл uber, который перебирает каждую сущность и вызывает некоторую функцию update / render / what.Это не масштабируется вообще, если каждое обновление, рендеринг или какая-либо другая иерархия не будут абсолютно одинаковыми.Это хорошо для такой игры, как Geometry Wars, но не для чего-то более сложного, чем это.

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

Некоторые полезные ссылки:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

Я настоятельно рекомендую оба;первый - это логическое обоснование построения игровых объектов из компонентов, то есть компонента рендеринга, компонента физики, компонента ИИ.Второе относится к характеристикам производительности различных подходов игровых сущностей.

Answer 2

Нет ничего плохого в том, что в ваших сущностях есть абстрактный метод Draw (), который позволяет им решать, как они будут рисоваться, особенно для небольших игр, которые, вероятно, не будут значительно расширены. Я использовал этот метод в куче небольших проектов, и он прекрасно работает.

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

Недавно я переключился на использование своих сущностей в качестве «тупых» контейнеров для интерфейсов, определяющих их поведение. Объект проигрывателя может содержать IMoveable, IControllable, IRenderable и многие другие интерфейсы, которые просто применяют специализированную операцию к этому объекту в зависимости от данных, которые он содержит. Сущность не знает об этом много, и все выполнение происходит, когда граф сцены просматривается для отбраковки / рендеринга.

Answer 3

Обычно я решаю эту проблему с наследованием .

Например, над проектом, с которым я сейчас работаю, я использую Test-Driven Development для написания логики игры, с ручным тестированием для рендеринга.Этот пример ниже в C # показывает грубую идею.

class GameObjecet {
    // Logic, nicely unit tested.
}

class DrawableGameObject : GameObject {
    // Drawing logic - manual testing
}

Это, как правило, лучшее решение.Это позволяет тестировать код, не перегружая игровую логику презентационным кодом, таким как рисование, загрузка моделей и т. Д. *

Answer 4

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

Тем не менее, нет причины, по которой вы не должны стремиться отделить состояние от представления. Субъектам не нужно знать, как рисовать себя как таковые - это означало бы, что они знают об операциях рендеринга, что не нужно - но должна быть возможность спросить их, как они выглядят в данный момент времени, а затем использовать эту информацию визуализировать сцену. например. 2D-объект должен иметь возможность вернуть свой текущий кадр анимации. Или 3D-объект должен иметь возможность возвращать свою 3D-сетку, положение и ориентацию. Здесь нет необходимости в операторе switch, если у вас есть общие представления, которые вы можете вернуть в средство визуализации. Сущности с сильно отличающимися алгоритмами рендеринга на этом этапе могут возвращать довольно разные объекты.