Архитектура каркаса игры - просмотр компонентов или MVC?

Question

Я пытаюсь создать очень легкий многоразовый фреймворк для моих игр, вместо того, чтобы начинать с нуля каждый раз, когда я запускаю игру. У меня есть компонентно-управляемая архитектура - например, Сущность состоит из компонента Position, компонента Health, компонента Ai и т. Д.

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

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

Answer 1

зависит от вашей аудитории, разработчики игр, в том числе и я, не очень привыкли к модели MVC, хотя большинство знает об этом, не так легко поддерживать чистоту, из-за потерь в разработке (не по каким-либо серьезным техническим причинам). Итак, по опыту я видел десятки игровых фреймворков, начинающихся как MVC, но только пара могла поддерживать его до конца. Моя теория заключается в том, что MVC добавляет слишком большую сложность и небольшие преимущества для небольших одноразовых игр (обычно с несколькими разработчиками), и трудно поддерживать четкое разделение большинства игровых объектов на эти слои для больших / сложных игр. А так как у игр есть дата выпуска, они много раз жертвуют ясностью кода и возможностью повторного использования для производительности и быстрых решений adhoc (которые будут переписаны, если потребуется в дальнейшем (если есть)).

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

Answer 2

Я бы определенно проголосовал за то, чтобы модель ничего не знала о ее взглядах. Слабая связь хороша: более простой код модели, более простое тестирование, больше вариантов выбора.

Answer 3

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

Answer 4

Я знаю, что этот вопрос может быть устаревшим, но мне нужно ответить на него. На самом деле, я начал программировать игру на Lua (с LÖVE) и начал программировать MVC-Framework для нее. Во-первых, использовать MVC действительно зависит от того, что вы хотите. Я знаю свои проблемы с программированием игр, когда программа становится больше, и в основном структура становится слишком сложной, чтобы ее поддерживать. Следующее, я знаю, что я изменю всю графику, когда найду художника, который готов работать для этого. Но до тех пор я буду использовать мою собственную фиктивную графику. Я хочу, чтобы художник не стеснялся делать то, что он хочет, не будучи зависимым от какого-либо разрешения или цветового ограничения. Это означает, что мне, возможно, придется изменить весь (!) Код презентации. Может быть, даже то, как объекты взаимодействуют (обнаружение столкновений, например). Логика игры отражена в моделях, поэтому я могу сосредоточиться на этом. И я думаю, что игровая логика - самая важная часть создания игры. Не так ли? Надеюсь, вы понимаете мою точку зрения.

Но, если у вас есть все вместе: вся графика, звуки, все это; тогда вы можете код прямо вперед.

Мой MVC - это задание по сравнению с соглашением, которое немного замедляет прототипирование. НО (!) Итерации разработки можно сделать намного проще. Тестирование, особенно юнит-тесты, выполняется намного быстрее. Я бы сказал, что MVC превращает вашу кривую скорости развития (которая обычно является антиэкспоненциальной кривой) в экспоненциальную кривую. Медленно в начале, но все быстрее и быстрее в конце.