Game framework architecture - просмотреть компоненты или MVC?

Question

Я пытаюсь создать очень легкую повторно используемую фреймворк для своих игр, а не начинать с нуля каждый раз, когда начинаю игру. У меня есть компонентная архитектура - например. Entity сочиняет компонент Позиции и компонент здравоохранения и Ай компонент и т.д.

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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